[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: thread ids, task ids and subsystems

From: Niels Möller
Subject: Re: thread ids, task ids and subsystems
Date: 10 Apr 2003 16:39:20 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Thanks for the excellent summary (in the other message). I have a few
questions and perhaps some answer, but I'll take it in separate

Marcus Brinkmann <address@hidden> writes:

> > (Either this, or the other extreme, let *every* hurdish port anywhere
> > in the system have one receiving thread per cpu).
> Yes, that was the other solution that came into my mind, and in fact I think
> that this probably wouldn't be too bad at all.

I'm afraid there's something basic I'm missing here. Say client thread
A sends a request to server thread B. I'd expect the following to

1. At the start, A is executing on cpu 1, and thread B is sleeping in
   a blocking RPC receive call.

2. Then the RPC happens. A is put to sleep, and B is scheduled for
   I'd expect L4 to schedule B on cpu 1, because (1) the thread that
   was running there was just put to sleep, so the cpu is free to
   take, and (2) the RPC arguments are located in *registers* inside
   cpu 1.

3. When B is finished, it replies and goes to sleep waiting for the
   next request (preferably by a *single* L4 RPC system call).

4. A is woken up, and again I'd expect it to be scheduled on cpu 1.
   With some luck, not all of it's context have been thrown out of the

This seems nice to me, and I don't see how having several server
threads makes it better. It also get's more complicated if the B
thread happens to be rescheduled onto a different cpu, say cpu 2,
during its processing. In this case, I'd expect A to be woken up and
scheduled on cpu 2, again so that the rpc operation don't cross cpu

Does it make sense at all to associate sleeping threads to cpu:s?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]