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/