l4-hurd
[Top][All Lists]
Advanced

[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: 11 Apr 2003 23:22:49 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Marcus Brinkmann <address@hidden> writes:

> On Fri, Apr 11, 2003 at 10:02:43PM +0200, Niels Möller wrote:
> > But we were also originally talking about the thread creation rpc, and
> > I guess that's a kind of special case with extra scheduling
> > requirements.
> 
> I don't really know if it is special.  I mean, if it's good for the thread
> interface, it can't be bad for the other interfaces.

For an ordinary rpc call from client A to server B, you have the
states

        A              B
  |  running        sleeping (blocking rpc receive)
  |        ---rpc-->
  |  sleeping       running
  |       <--reply---
  |  running        sleeping
  V
 time

So it's possible (and I thought it was also desirable, although now
I'm no longer sure about that) to schedule A and B on the same cpu.

But for thread creation, there's a third thread C being created, so
you get

        A              B           C
  |  running        sleeping      nil
  |        ---rpc-->
  |  sleeping       running     created
  |       <--reply---
  |  running        sleeping    running (if there was a free cpu)
  V
 time

So if you have a free cpu, you want both C and A running on different
cpu:s at the end of the call, and it's not obvious to me which one of
them it's best to have B scheduled on. Probably easiest to have A nd B
on the same cpu ant put C on the free one.

And if you don't have a free cpu, you have to decide which one of C
and A gets to execute first, and that also affects scheduling.

> BTW, yesterday I worked out a scheme which would allow multi-threaded
> servers as well as single-threaded servers.  If the server thread id has the
> lower N bits (which represent the processor number) all 0, this server would
> then (by definition) be multi threaded [...]
> 
> Unfortunately, this does not allow for processor sets.  If we were to allow
> more flexibility, we would need a much more complicated scheme.

Sounds flexible enough to me, but I'm not sure what processor sets
mean here.

Regards,
/Niels




reply via email to

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