[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: |
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
- Re: thread ids, task ids and subsystems, (continued)
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/08
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/08
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/10
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/10
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/11
- Re: thread ids, task ids and subsystems, Espen Skoglund, 2003/04/11
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/11
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/11
- Re: thread ids, task ids and subsystems,
Niels Möller <=
- Re: thread ids, task ids and subsystems, Espen Skoglund, 2003/04/11
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/11
- Re: thread ids, task ids and subsystems, Espen Skoglund, 2003/04/11
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/10
- Re: thread ids, task ids and subsystems, Marcus Brinkmann, 2003/04/10
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/10
- Re: thread ids, task ids and subsystems, Maurizio Boriani, 2003/04/10
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/10
- Re: thread ids, task ids and subsystems, Maurizio Boriani, 2003/04/10
- Re: thread ids, task ids and subsystems, Niels Möller, 2003/04/10