Messages in this thread | | | Date | Sun, 11 Jan 1998 16:55:23 -0500 (EST) | From | Christopher Blizzard <> | Subject | Re: RedHat 5.0 and threads |
| |
On Sun, 11 Jan 1998, linux kernel account wrote:
: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 ------------
| |