Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?

[Farid Hajji]

> > The reason why we need an N:M library is, that we are planning to port
> > the Hurd from Mach to the L4 microkernel. Unfortunately, the Hurd uses
> > threads very heavily, and L4 provides only a limited number of native
> > threads per task (128 or so), so there is a need for a multiplexing
> > library.
> 
> When you seriously start looking at an L4 port, I suggest you start
> out by using a 1:1 user--kernel thread mapping.  I suggest this for
> two reasons.  First, in practice the limit of kernel threads per task
> has rarely been a problem in L4 development.  Second, as IPC messages
> in L4 are addressed to kernel threads, using an N:M mapping
> complicates matters.
In practice the Hurd servers use quite a lot of threads. For example,
current filesystem servers use one thread per open file and it is not
uncommon to have mach tasks with say 250 simultaneous threads on a
midely loaded system. Of course, this liberal usage of threads could
be curbed in the Hurd itself, e.g. by pooling threads and limiting the
maximum parallelism. The Hurd designers choose not to do so because
they wanted to benefit from Mach implementations for massively
parallel systems (that was quite a biggy back then) and they
argumented, that a uKernel and its associated threading libraries
should provide a very high number of threads and that it should not be
a matter of application specific code to deal with such restrictions.

It seems that the thread-client Hurd code should not be modified
substantially (e.g. by pooling), but that a library should provide
for the N:M mapping (even on systems where N >> M ). Is this realistic?
Hmmm... I'd prefer to leave this out at the moment and concentrate on
real work.

It's okay to use a rather limited number threads for initial experiemnts
though...

> That said, I think I know of three free N:M thread libraries:
> 
> - Already mentioned on this mailing list: Next Generation POSIX
>   Threading Project --
>   <URL:http://oss.software.ibm.com/developerworks/opensource/pthreads/>
> 
> - Last USENIX had a paper about a Solaris-compatible thread library --
>   <URL:http://www.usenix.org/events/usenix01/freenix01/wood.html>.
>   Solaris has N:M threading, and the library is said to be
>   API-compatible, but I don't know if it also implements N:M.
Thanks for the pointers. I lost the reference of that Usenix paper
before being able to grab it and somewhere l4-hurd already mentioned
a pthreads library written by IBM but without providing any further
references. That's a lot to study for the next days ;-)

> - Isn't Mach's cthreads library also an N:M implementation?
Huh? I must have missed something here. To me, C-Threasd was just a
wrapper to Mach's threads so I didn't bother look at them more
closely (shame on me). I'll obviously have to be more careful
next time! Thanks so much for pointing this out. And yes... you
hinted this in beleg.ps already and it did catch my attention ;-).

Right now, I'm studying the code of Birrel's uthread library as
present in FreeBSD's libc_r. That's also quite instructive, but
it needs time to really understand it.

Regards,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.