l4-hurd
[Top][All Lists]
Advanced

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

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


From: Farid Hajji
Subject: Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?
Date: Tue, 24 Jul 2001 15:32:33 +0200

> > 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. 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. 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?

It may be possible to retarget the Hurd's IPC mechanism in such a
way, that fewer kernel-threads are needed (using message queues etc..),
but I can't see the far reaching consequences yet.

Why is it such a problem for L4 to support a larger number of threads?
 1. thread-id has too few bits?
 2. run-queues get too large?
 3. other reasons?

Is 1. really a limitation? I don't know about x86, but with 64-bit CPUs
or with CPUs with large register sets, the thread-id field could easily
be much bigger.

2. can be a problem, because the total size of the kernel would grow,
therefore filling the caches. Traversing the queues is not the issue,
since insert() and pop()- operations are O(1).

Are there plans to support a larger number of threads or a N:M thread
model in future L4 versions?

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.




reply via email to

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