[Top][All Lists]
[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.
- LinuxThreads or other alternatives for the Hurd/{Mach,L4}?, Farid Hajji, 2001/07/20
- Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?, Michael Hohmuth, 2001/07/22
- Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?, Farid Hajji, 2001/07/22
- Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?, Michael Hohmuth, 2001/07/23
- Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?,
Farid Hajji <=
- Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?, Espen Skoglund, 2001/07/24
- Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?, Farid Hajji, 2001/07/24
- Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?, Michael Hohmuth, 2001/07/25