:I've found Linux thread support to be mostly satsfactory.
:
:We all need to remember the reason for threads in other OSes:
:HORRIBLE CONTEXT SWITCH TIME.
:
:As I recall, this is not so much an issue with Linux as it's normal
:process context switch time is only slightly worse then the thread switch
:time under solaris.
:
Actually, the reason that I use threads is more of a design than a
performance issue. There are a lot of places where a threaded design will
buy you a lot, especially when you're writing network services. True, one
advantage of using threads is a lower context switch time on some OS' but
context times on Linux are pretty low already so that's not so much of an
issue.
However, some threading performance ( note: not context switches ) numbers
that I have seen have actually rated Linux the lowest behind solaris,
digital unix and Win32. The reason for this ( I think ) is the way that
pthreads is implemented. Linuxthreads uses signals with a manager thread
to do much of the thread managment and I'm speculating that that may be
part of the problem.
This is also a problem with the current pthreads implementation...it uses
SIGUSR1 and SIGUSR2 to communicate between the manager thread and the
child threads. This may seem fine but there are applications out there
that use those signals, an example being Sun's JDK. I looked into doing a
native port but had to throw it out the window because of that.
Some thread support in the kernel would help alleviate these problems. I
realize there's an argument that threads belong in userland and the kernel
should just provide the methods for creating new threads of execution
which seems to be the way that things are done right now. I think that
this is causing a lot of problems though.
I would centend, only from speculation, that moving some things out of
userland and into the kernel would actually help. Right now with the use
of a manager thread with signals has to be really expensive ( how
expensive is signal delivery vs. a regular context switch anyway? someone
with more experience should comment on this ). Moving simple thread
constructs into the kernel like semaphores, mutexes and reader-writer
locks would really help make things more elegant. Also, race
conditions especially on multi-processor machines would probably be less
of a problem.
Also, if there was a ptrace or /proc interface, adding the needed features
to the debugger would be a lot easier as well. You could stop all
threads, start threads, list the state of all your mutexes and semaphores
all through one interface. This is something that the debugger really
needs and I would imagine that it's tougher to add this to a userland
threads implementation than a kernel based one.
Of course all of this is just speculation on my part. I'm not a kernel
hacker....yet. :) Getting a dialogue running about this is what I'm
really intereted in. I would like to see what people who have more
experience dealing with implementing these kinds of systems have to say
about the performance and design problems that come from what I'm
suggesting here.
--Chris
------------
Christopher Blizzard
AppliedTheory Communications, Inc.
http://odin.appliedtheory.com/
blizzard@appliedtheory.com
------------