pthread_cond_signal vs. pthread_cond_broadcast
Joe Seigh
given that you can do everything with pthread_cond_broadcast
that you could with pthread_cond_signal? Also, since
pthread_cond_signal is defined as waking up at least one
waiting thread, pthread_cond_signal could be a synonym for
pthread_cond_broadcast.
If there was, say, a condition variable implementation using
semaphores (not pthreads but pthread like w/ processes)
would the absence of a proper cond_signal function well neigh
make it useless? Just a theorectial curiosity here
and not necessarily an indication that I am actually doing
anything in this area, especially in Perl.
Joe Seigh
Srikant Sharma
acondvar. But in case of pthread_cond_signal it's almost always
a single thread that is being woken up.
Neverthless the contention for the mutex that should be acquired
after waking up is not same for the sleeping threads in both cases.
Also if the event is such that it can be consumed by exactly one thread
then there is no point in waking up 'all the threads' but 'atleast one'
thread should be woken up for this purpose.
--
Srikant
Kaz Kylheku
>Is pthread_cond_signal really all that necessary or essential
>given that you can do everything with pthread_cond_broadcast
>that you could with pthread_cond_signal? Also, since
>pthread_cond_signal is defined as waking up at least one
>waiting thread, pthread_cond_signal could be a synonym for
>pthread_cond_broadcast.
That's right. If you are ever implementing this interface, and are stuck making
a pthread_cond_signal that wakes up only one thread, don't sweat it: just make
it wake up more than one.
However pthread_cond_signal is very useful in optimizing the performance
of a multithreaded application. It's waste of time to wake up many threads
to respond to something that only one thread is possibly eligible for.
It's sort of like throwing a steak into yard full of dogs. ;)
--
#exclude <windows.h>
Patrick TJ McPhee
Joe Seigh <jse...@genuity.com> wrote:
% Is pthread_cond_signal really all that necessary or essential
% given that you can do everything with pthread_cond_broadcast
% that you could with pthread_cond_signal? Also, since
Dave Butenhof has pointed out on a few occasions that _cond_signal
was meant purely as an optimisation for the common case when you
know only one thread can respond to a condition. What people using posix
condition variables always have to remember is that spurious
wake-ups are allowed. The condition variable doesn't indicate
state, it's just a signalling mechanism, so if _cond_signal is
just a synonym for _cond_broadcast, you could think of it as
1 signal and n-1 spurious wake-ups, where n is the number of threads
waiting on the condition variable, and the application has to
be able to handle that.
--
Patrick TJ McPhee
East York Canada
pt...@interlog.com
Joe Seigh
the previous posts. That's one of those self inflicted problems
due to architecting in characteristics of the original pthreads
implementations. It's just that pthread_cond_signal is so
problematic. It puts an aspect of thread control in a place where
it has no business being. Instead of a nice constraint driven
program design, you have all this thread scheduling and control
cluttering up all that design. And it's probably fairly error
prone. You either have signals lost because they were picked
up by the wrong thread which then for one reason or another
didn't repropagate it, or you have programs that can't deal with
the spurious signals as too few people realize this can happen.
It's too easy to say, well, that's the responsibility of the
programmer to use the programming api's correctly, but it's
a design quality issue as to whether you've designed an api that
more or less encourages or forces correct usage, or makes it
easy to make mistakes. pthread_cond_signal fails in this respect.
It also means that probably no one has really spent time on researching
what would be the cleanest and best way to address this issue. I
can think some other approaches, so there is at least one.
So at this point I think it would be irresponsible to propagate the
cond_signal (vs. cond_broadcast) interface in new designs. The
"thundering herd" problem is a problem but it's certainly not a
compelling issue.
Joe Seigh