Messages in this thread | | | Date | Tue, 27 Apr 1999 17:21:05 -0700 | From | Mike Touloumtzis <> | Subject | Re: Linus on Linux, Apache and Threads |
| |
On Tue, Apr 27, 1999 at 04:16:36PM +0100, Tony Gale wrote: > > Except these don't actually answer the question. There are a couple > of issues here: > > o Signals > o Wake-one-thread > o PIDs > > Signals: LinuxThreads has traditionally used SIGUSR1 and SIGUSR2 to > do it's internal work. Looking at the source code, it looks like > glibc 2.1 with recent kernels will use the RT Signals instead. This > is good. >
Yup.
> Wake-one-thread: The function pthread_cond_signal is supposed to wake > a single thread that is waiting on the condition variable. However, a > number of people in this forum have hinted that this is not so, and > that all threads are awakened. Hence, lots of talk of thundering > herds. Is this all just a mistake? If so, this is bad. >
Disclaimer: I'm not a kernel hacker (not on the linux kernel, at least). But I think you may be referring to the LinuxThreads implementation anyway, which isn't in the kernel AFAIK.
The thundering herds problem described in this thread is an implementation detail, not an API detail. Either way (with "true" wake-one or thundering herds) semaphores have the same semantics from an application perspective.
It's just that with the thundering herds approach, threads are all woken (temporarily) to re-contend for the semaphore. One wins, the others go back to sleep. This approach is easier to implement at a low level when you might have (for example) both interrupt handlers and in-kernel process contexts releasing semaphores. Outside the kernel, an analagous situation applies w/ signal handlers and threads.
> PIDs: LinuxThreads assign a different process id to each thread, > even though they have lightweight context switching - this leads to > much confusion with people who don't know about CLONE. [Haven't > checked the glibc 2.1 position on this one.] >
Some OSes have true lightweight thread switching (it takes place entirely in userspace). It's very fast, but isn't SMP friendly, and interacts poorly with blocking OS calls. Many Un*x OSes have two-tiered thread implementations (both kernel thread switching and userspace thread switching). This works pretty well but is complex.
Linux (and LinuxThreads), to the best of my knowledge--this might have changed with glibc 2.1, I don't know a lot about it--only uses kernel threads, each with its own PID. The "lightweight" to which people have been referring is that you don't take as big a hit when switching to another thread of the same process, since the MMU-related CPU context remains the same across the switch.
> I'm beginning to think that there is a misconception with linux and > the wake-one-thread issue, and that it does, indeed, wake a single > thread. I see no reason, given the signalling mechanism and the PID > stuff that it should do anything different. > > -tony >
Hope this helps.
miket
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |