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

[Michael Hohmuth]

Farid Hajji <address@hidden> writes:

> > > It's okay to use a rather limited number threads for initial experiemnts
> > > though...
> > 
> > Yes.  However, you need to avoid the trap of becoming too tied to any
> > kernel-specific threading and IPC interface.  I suggest using a subset
> > of pthreads for threading, and an RPC mechanism to hide the coupling
> > between IPC and threads.

> I'm not sure if I understand you fully here. Could you please expand
> a little bit more on this?
> 
> As you pointed out, L4-threads are the recipients of IPC. 

This is very system-specific behavior.  Therefore, you should abstract
away from IPC (and threads as the recipients of IPC) in your
portability interface (KAL).

Use a system-independent threading interface, an RPC mechanism to hide
IPC, and a custom abstraction for RPC destination.  The destination
abstraction should not be a thread ID; instead, it can be similar to
Mach's ports, but with much simpler semantics (an opaque object the
KAL can use to find the destination for a synchronous call).

> A user-level thread that needs to receive a message would therefore
> block the currently associated kernel-thread. Because most [user-
> and kernel-] threads would normally be blocked on a msg_receive, it
> could well turn out, that using a N:M-threads library would not
> yield a higher number of threads anyway.  

(In this discussion I assume that we use an L4 implementation with a
limited number of kernel threads, and that the Hurd is not changed
significantly to accommodate to this limitation; that is, an N:M
thread multiplexing library is required.)

A user-level threading implementation that blocks a whole kernel
thread because one user-level thread does an IPC would be a very bad
idea indeed.  I can think of a KAL implementation (of the interface I
proposed above) for L4 that is more effective than what you sketched
here.

> Besides, there is also the performance hit associated with calling
> the user-level scheduler (and a message demuxer) when a
> kernel-thread returns from msg_receive(). Most benefits from a fast
> IPC-path would be lost, won't they?

I don't think this is a costly operation.  

If it turns out to be a problem, an easy optimization would be to use
one of the thread-group mechanisms for L4 that were recently proposed
(and presumably already implemented in L4KA?) where a message
addressed to a thread that is currently not waiting (because it is
busy or blocked in another IPC) is automatically redirected to the
next waiting thread.

With such a thread-group mechanism, a kernel thread that receives a
message can just resume the user thread that waits for it.

> Why is it such a problem for L4 to support a larger number of threads?

It's not.  Espen already answered that question: The limitation will
be addressed in a future version of the L4 interface.

However, all production kernels have the limitation, partly because
L4's designer, Jochen Liedtke, thought that an efficient user-level
threading library was possible, and I tend to agree with him here.

Michael
-- 
address@hidden, address@hidden
http://home.pages.de/~hohmuth/