Even though I've been doing threads programming for years I've always
avoided this function call because I never understood the point of it
with condition variables. Ie: because all threads contend to lock the
associated mutex only one actually exits the wait call anyway, so whats
the point of using this instead of cond_signal?

Muttley@dastardlyhq.com, dans le message <trqgmc$312l3$1@dont-email.me>,
a écrit :
> Even though I've been doing threads programming for years I've always
> avoided this function call because I never understood the point of it
> with condition variables. Ie: because all threads contend to lock the
> associated mutex only one actually exits the wait call anyway, so whats
> the point of using this instead of cond_signal?

An example of use:

https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/frame_thread_encoder.c

On 06 Feb 2023 10:50:30 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>Muttley@dastardlyhq.com, dans le message <trqgmc$312l3$1@dont-email.me>,
> a �crit�:
>> Even though I've been doing threads programming for years I've always
>> avoided this function call because I never understood the point of it
>> with condition variables. Ie: because all threads contend to lock the
>> associated mutex only one actually exits the wait call anyway, so whats
>> the point of using this instead of cond_signal?
>
>An example of use:
>
>https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/frame_thread_enc
>oder.c

Far too complex to be helpful.

Muttley@dastardlyhq.com, dans le message <trqn7r$3278q$1@dont-email.me>,
a écrit :
> Far too complex to be helpful.

You do not need to read all of it to see why the function if used. But fine,
suit yourself.

On 06 Feb 2023 12:28:44 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>Muttley@dastardlyhq.com, dans le message <trqn7r$3278q$1@dont-email.me>,
> a �crit�:
>> Far too complex to be helpful.
>
>You do not need to read all of it to see why the function if used. But fine,
>suit yourself.

I read it. Its no help. As far as I can see it could use signal instead of
broadcast.

Muttley@dastardlyhq.com writes:
> Even though I've been doing threads programming for years I've always
> avoided this function call because I never understood the point of it
> with condition variables. Ie: because all threads contend to lock the
> associated mutex only one actually exits the wait call anyway, so whats
> the point of using this instead of cond_signal?

I've yet to encounter a situation where this is useful myself. SUS
names, single-producer/ multiple consumers, writer releases a rw lock,
and two-phase commit as examples. OTOH, it's unclear (to me at least)
why one shouldn't use signal to wake up one thread which could resignal
in case there's more work to do than it plans to handle.

On 2023-02-06, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> Even though I've been doing threads programming for years I've always
> avoided this function call because I never understood the point of it
> with condition variables. Ie: because all threads contend to lock the
> associated mutex only one actually exits the wait call anyway, so whats
> the point of using this instead of cond_signal?

You should always reach for pthread_cond_broadcast in initial designs
and implementaitons, because it will more easily assure correctness.

In a correct program, every pthread_cond_signal can be replaced with
pthread_cond_broadcast without sacrificing correctness. The reverse
isn't true.

pthread_cond_signal is an optimization for the case when you are
absolutely sure that the program will still behave correctly if only
at most one thread is woken.

(I seem to recall that no function guarantees that no more than one
thread will wake up; programs must be prepared for spurious wakeups.)

There are situations in which making some Boolean condition true means
that any number of threads are unblocked, not only one. For instance
a ready-wait: one or more threads are blocked waiting for some API
to become ready for service.

A situation where you need at most one thread to wake up is when
implementing a counting semaphore.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Muttley@dastardlyhq.com writes:
>> Even though I've been doing threads programming for years I've always
>> avoided this function call because I never understood the point of it
>> with condition variables. Ie: because all threads contend to lock the
>> associated mutex only one actually exits the wait call anyway, so whats
>> the point of using this instead of cond_signal?
>
> I've yet to encounter a situation where this is useful myself. SUS
> names, single-producer/ multiple consumers, writer releases a rw lock,
> and two-phase commit as examples. OTOH, it's unclear (to me at least)
> why one shouldn't use signal to wake up one thread which could resignal
> in case there's more work to do than it plans to handle.

Suppose you have a "bool api_ready = false" flag, with a condition and
mutex. Threads must wait for the API to become ready before using it:

void api_wait()
{
pthread_mutex_lock(&api_mutex);
while (!api_ready)
pthread_cond_wait(&api_cond, &api_mutex);
pthread_mutex_ulock(&api_mutex);
}

void api_ready()
{
pthread_mutex_lock(&api_mutex);
api_ready = true;
pthread_mutex_ulock(&api_mutex);
// pthread_cond_signal, or pthread_cond_broadcast?
}

How would you complete api_ready?

If you chose signal, how would you code around the fact that
only one thread was woken up to use the API?

Do you put a just-in-case pthread_cond_signal into every single API
call?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Mon, 6 Feb 2023 22:30:39 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-02-06, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> Even though I've been doing threads programming for years I've always
>> avoided this function call because I never understood the point of it
>> with condition variables. Ie: because all threads contend to lock the
>> associated mutex only one actually exits the wait call anyway, so whats
>> the point of using this instead of cond_signal?
>
>You should always reach for pthread_cond_broadcast in initial designs
>and implementaitons, because it will more easily assure correctness.
>
>In a correct program, every pthread_cond_signal can be replaced with
>pthread_cond_broadcast without sacrificing correctness. The reverse
>isn't true.
>
>pthread_cond_signal is an optimization for the case when you are
>absolutely sure that the program will still behave correctly if only
>at most one thread is woken.

But why? Regardless of which call you use only 1 waiting thread exits the
pthread_cond_wait() call so what difference does it make? The ONLY difference
I have found is that signal wakes up threads in a particular order (seems to
be creation order on MacOS) so you know which thread will exit wait() whereas
broadcast wakes them all up and a random thread exits wait(). However I can't
see how that is any kind of advantage if the threads are all executing the
same code anyway.

Muttley@dastardlyhq.com, dans le message <trt544$3guf1$1@dont-email.me>,
a écrit :
> But why? Regardless of which call you use only 1 waiting thread exits the
> pthread_cond_wait() call so what difference does it make?

I consider Kaz's answer to be nonsense. Signal is absolutely not just an
optimization over broadcast: they have clear semantics and are to be used in
different circumstances. The FFmpeg code I quoted gives a very good example
of these different circumstances.

On 07 Feb 2023 09:34:57 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>Muttley@dastardlyhq.com, dans le message <trt544$3guf1$1@dont-email.me>,
> a �crit�:
>> But why? Regardless of which call you use only 1 waiting thread exits the
>> pthread_cond_wait() call so what difference does it make?
>
>I consider Kaz's answer to be nonsense. Signal is absolutely not just an
>optimization over broadcast: they have clear semantics and are to be used in
>different circumstances. The FFmpeg code I quoted gives a very good example
>of these different circumstances.

How about explaining it then because I can't see it.

On 06/02/2023 20:19, Muttley@dastardlyhq.com wrote:
> Even though I've been doing threads programming for years I've always
> avoided this function call because I never understood the point of it
> with condition variables. Ie: because all threads contend to lock the
> associated mutex only one actually exits the wait call anyway, so whats
> the point of using this instead of cond_signal?
>
What I was told, a couple of decades ago, was that _signal meant that
(usually/mostly/maybe/probably) only one thread waiting on that signal
would wake up, whereas _broadcast meant that *all* threads waiting on
that signal would wake. (I think it may have been by David Butenhof, I
kind of trust him. (And it may have been DEC Alpha-specific.))

So, frex, if you have multiple consumers waiting on data that is being
fed into a single queue, starting them all up when something is
available can drain the queue faster, as data may be added while they
are waiting on the queue mutex. Sort of. Worked for me. :-)

Cheers,
Gary B-)

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-02-06, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Muttley@dastardlyhq.com writes:
>>> Even though I've been doing threads programming for years I've always
>>> avoided this function call because I never understood the point of it
>>> with condition variables. Ie: because all threads contend to lock the
>>> associated mutex only one actually exits the wait call anyway, so whats
>>> the point of using this instead of cond_signal?
>>
>> I've yet to encounter a situation where this is useful myself. SUS
>> names, single-producer/ multiple consumers, writer releases a rw lock,
>> and two-phase commit as examples. OTOH, it's unclear (to me at least)
>> why one shouldn't use signal to wake up one thread which could resignal
>> in case there's more work to do than it plans to handle.
>
> Suppose you have a "bool api_ready = false" flag, with a condition and
> mutex. Threads must wait for the API to become ready before using it:
>

static unsigned waiting;

>
> void api_wait()
> {

unsigned more;

> pthread_mutex_lock(&api_mutex);

if (!api_ready) {
++waiting;
do pthread_cond_wait(&api_cond, &api_mutex); while (!api_ready);
more = --waiting;
> pthread_mutex_ulock(&api_mutex);
if (more) pthread_cond_signal(&api_cond);
}
> }
>
> void api_ready()
> {
> pthread_mutex_lock(&api_mutex);
> api_ready = true;
> pthread_mutex_ulock(&api_mutex);
pthread_cond_signal(&api_cond);
>
> How would you complete api_ready?
>
> If you chose signal, how would you code around the fact that
> only one thread was woken up to use the API?

It's not particularly difficult to code this without thundering nerds.

On Wed, 8 Feb 2023 00:54:51 +1100
"Gary R. Schmidt" <grschmidt@acm.org> wrote:
>On 06/02/2023 20:19, Muttley@dastardlyhq.com wrote:
>> Even though I've been doing threads programming for years I've always
>> avoided this function call because I never understood the point of it
>> with condition variables. Ie: because all threads contend to lock the
>> associated mutex only one actually exits the wait call anyway, so whats
>> the point of using this instead of cond_signal?
>>
>What I was told, a couple of decades ago, was that _signal meant that
>(usually/mostly/maybe/probably) only one thread waiting on that signal
>would wake up, whereas _broadcast meant that *all* threads waiting on
>that signal would wake. (I think it may have been by David Butenhof, I
>kind of trust him. (And it may have been DEC Alpha-specific.))

Yes, that is the official position and in the OS kernel all the threads
may well get woken up. However from the application program POV there's no
difference because only 1 thread exits pthread_cond_wait() per signal or
broadcast sent.

>So, frex, if you have multiple consumers waiting on data that is being
>fed into a single queue, starting them all up when something is
>available can drain the queue faster, as data may be added while they
>are waiting on the queue mutex. Sort of. Worked for me. :-)

I don't follow. For 1 condition signal/broadcast 1 thread exits a wait call.
If multiple threads exited the wait then that would be a useful paradigm
but AFAIK pthreads doesn't supply that functionality.

Muttley@dastardlyhq.com writes:
>On Wed, 8 Feb 2023 00:54:51 +1100
>"Gary R. Schmidt" <grschmidt@acm.org> wrote:
>>On 06/02/2023 20:19, Muttley@dastardlyhq.com wrote:
>>> Even though I've been doing threads programming for years I've always
>>> avoided this function call because I never understood the point of it
>>> with condition variables. Ie: because all threads contend to lock the
>>> associated mutex only one actually exits the wait call anyway, so whats
>>> the point of using this instead of cond_signal?
>>>
>>What I was told, a couple of decades ago, was that _signal meant that
>>(usually/mostly/maybe/probably) only one thread waiting on that signal
>>would wake up, whereas _broadcast meant that *all* threads waiting on
>>that signal would wake. (I think it may have been by David Butenhof, I
>>kind of trust him. (And it may have been DEC Alpha-specific.))
>
>Yes, that is the official position and in the OS kernel all the threads
>may well get woken up. However from the application program POV there's no
>difference because only 1 thread exits pthread_cond_wait() per signal or
>broadcast sent.
>
>>So, frex, if you have multiple consumers waiting on data that is being
>>fed into a single queue, starting them all up when something is
>>available can drain the queue faster, as data may be added while they
>>are waiting on the queue mutex. Sort of. Worked for me. :-)
>
>I don't follow. For 1 condition signal/broadcast 1 thread exits a wait call.
>If multiple threads exited the wait then that would be a useful paradigm
>but AFAIK pthreads doesn't supply that functionality.

If you use broadcast, all threads waiting on the condition variable
will be made runnable. Then they will all immediately contend for
the mutex that was temporarily dropped while waiting on the event,
particularly if there are enough cores to run them all in parallel
and the scheduling constraints (e.g. thread priorities) allow the
newly runnable threads to be assigned to a physical thread/core.

This is known as a thundering herd.

On Tue, 07 Feb 2023 16:33:34 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>On Wed, 8 Feb 2023 00:54:51 +1100
>>"Gary R. Schmidt" <grschmidt@acm.org> wrote:
>>>On 06/02/2023 20:19, Muttley@dastardlyhq.com wrote:
>>>> Even though I've been doing threads programming for years I've always
>>>> avoided this function call because I never understood the point of it
>>>> with condition variables. Ie: because all threads contend to lock the
>>>> associated mutex only one actually exits the wait call anyway, so whats
>>>> the point of using this instead of cond_signal?
>>>>
>>>What I was told, a couple of decades ago, was that _signal meant that
>>>(usually/mostly/maybe/probably) only one thread waiting on that signal
>>>would wake up, whereas _broadcast meant that *all* threads waiting on
>>>that signal would wake. (I think it may have been by David Butenhof, I
>>>kind of trust him. (And it may have been DEC Alpha-specific.))
>>
>>Yes, that is the official position and in the OS kernel all the threads
>>may well get woken up. However from the application program POV there's no
>>difference because only 1 thread exits pthread_cond_wait() per signal or
>>broadcast sent.
>>
>>>So, frex, if you have multiple consumers waiting on data that is being
>>>fed into a single queue, starting them all up when something is
>>>available can drain the queue faster, as data may be added while they
>>>are waiting on the queue mutex. Sort of. Worked for me. :-)
>>
>>I don't follow. For 1 condition signal/broadcast 1 thread exits a wait call.
>>If multiple threads exited the wait then that would be a useful paradigm
>>but AFAIK pthreads doesn't supply that functionality.
>
>If you use broadcast, all threads waiting on the condition variable
>will be made runnable. Then they will all immediately contend for
>the mutex that was temporarily dropped while waiting on the event,
>particularly if there are enough cores to run them all in parallel
>and the scheduling constraints (e.g. thread priorities) allow the
>newly runnable threads to be assigned to a physical thread/core.
>
>This is known as a thundering herd.

Its also invisible to the application program so I still don't see what the
difference and/or advantage of using broadcast vs signal is to the application.

Muttley@dastardlyhq.com writes:
> On Tue, 07 Feb 2023 16:33:34 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>>Muttley@dastardlyhq.com writes:

[...]

>>>I don't follow. For 1 condition signal/broadcast 1 thread exits a wait call.
>>>If multiple threads exited the wait then that would be a useful paradigm
>>>but AFAIK pthreads doesn't supply that functionality.
>>
>>If you use broadcast, all threads waiting on the condition variable
>>will be made runnable. Then they will all immediately contend for
>>the mutex that was temporarily dropped while waiting on the event,
>>particularly if there are enough cores to run them all in parallel
>>and the scheduling constraints (e.g. thread priorities) allow the
>>newly runnable threads to be assigned to a physical thread/core.
>>
>>This is known as a thundering herd.
>
> Its also invisible to the application program so I still don't see
> what the difference and/or advantage of using broadcast vs signal is
> to the application.

I think that was supposed to describe a disadvantage. :-)

My guess why this interface exists would be that it's historical baggage
instinctively carried over from the UNIX kernel by people who were
accustomed to it. In order to wait for an event, a process executing
kernel code would go to sleep on a so-called sleep channel identified by
a pointer. This would typically be the address of a kernel variable
associated with the event the process wanted to wait for. This sleep
channel identifier was hashed to map it to a sleep queue and the process
would then put onto this sleep queue. At some later time, some other
code also executing in the kernel would do a wake up call using a sleep
channel identifer. This would cause all processes on the corresponding
sleep queue to be woken up. This had to be done because there was no way
to determine what event a process using a certain sleep channel
identifier was actually interested in (and possibly, because of hash
collisions in case the actual sleep channel identifier a process had
used wasn't stored anywhere).

With pthread_cond_broadcast, a condition variable can act as sleep
channel: It's possible to write a program such that it uses a single
condition variable for everything some thread might need to wait for. If
this was done, broadcast wakeup would be needed for the same reason it
was needed for UNIX sleep channels.

Rainer Weikusat <rweikusat@talktalk.net> writes:
> Muttley@dastardlyhq.com writes:

[...]

>> I still don't see
>> what the difference and/or advantage of using broadcast vs signal is
>> to the application.

[...]

> My guess why this interface exists would be that it's historical baggage
> instinctively carried over from the UNIX kernel by people who were
> accustomed to it. In order to wait for an event, a process executing
> kernel code would go to sleep on a so-called sleep channel identified by
> a pointer.

[...]

> With pthread_cond_broadcast, a condition variable can act as sleep
> channel

[...]

Slight correction: It can act as sleep queue for any number of sleep
channels, ie, the original UNIX sleep/ wakeup mechanism can be
implemented with the help of a condition variable or an array of condition
variables sleep channel IDs are hashed onto.

On 2023-02-07, Nicolas George <nicolas$george@salle-s.org> wrote:
> Muttley@dastardlyhq.com, dans le message <trt544$3guf1$1@dont-email.me>,
> a écrit :
>> But why? Regardless of which call you use only 1 waiting thread exits the
>> pthread_cond_wait() call so what difference does it make?
>
> I consider Kaz's answer to be nonsense. Signal is absolutely not just an
> optimization over broadcast: they have clear semantics and are to be used in

I explained very clearly that it's not that kind of optimization where
we improve something, but the semantics stays the same (as in "compiler
optimization").

It definitely has different semantics; it gives you an optimization when
it is unnecessary and wasteful (or even pathologic) for more than one
thread to wake up.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-02-07, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> Yes, that is the official position and in the OS kernel all the threads
> may well get woken up. However from the application program POV there's no
> difference because only 1 thread exits pthread_cond_wait() per signal or
> broadcast sent.

That is simply false. It's true that only one waiting thread at a time
can exit from the function. But that's because of the mutex.

If you broadcast the condition, all threads waiting on the condition
will wake up and contend for the mutex.

Threads contenting for the mutex proceed when the mutex is available.

Threads sleeping on the condition variable do not proceed regardless
of what is happening with the mutex.

> If multiple threads exited the wait then that would be a useful paradigm
> but AFAIK pthreads doesn't supply that functionality.

Yes it does! If you need the paradigm of multiple threads being
woken up together without having to pass serially through a mutex,
POSIX provides barriers: pthread_barrier_wait.

It is indeed useful for parallel processing.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-02-07, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> Its also invisible to the application program so I still don't see
> what the difference and/or advantage of using broadcast vs signal is
> to the application.

It is completely visible to the application. Compare:

"Ten threads have been woken up and are contending for the mutex in
order the all return from their respective pthread_cond_wait calls."

"One threads has been woken up and is contending for the mutex in
order to return from pthread_cond_wait."

Do you understand the api_ready example? Here it is again:

bool api_ready = false;
pthread_mutex_t api_ready_mutex = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t api_ready_cond = PTHREAD_COND_INITIALIZER;

// internal function: indicates API is ready
static void api_becomes_ready(void)
{
pthread_mutex_lock(&api_mutex);
api_ready = true;
pthread_mutex_unlock(&api_mutex);
pthread_cond_broadcast(&api_cond); // wake up everyone
}

void api_ready_wait(void)
{
pthread_mutex_lock(&api_mutex);
while (!api_ready)
pthread_cond_wait(&api_cond, &api_mutex);

// Yes, only one thread can be here at a time

pthread_mutex_unlock(&api_mutex);

// Multiple threads can be returning here.
}

The api_becomes_ready function is called exactly once by the API
itself to indicate that it is ready.

Muliple threads from different subsystems may have called api_ready_wait
in order to wait for this indication.

If pthread_cond_signal is used, then quite likely, only one of those
threads will wake up; the others will stay stuck forever.

You can code this up and try it.

I think the subtlety you're missing is what I commented on in the code:
although exit from pthread_cond_wait is serialized due to the mutex,
exit from the surrounding function api_ready_wait isn't; mutiple threads
can be exiting from that function. The serialization through the mutex
is just a local speedbump.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-02-07, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> Its also invisible to the application program so I still don't see
>> what the difference and/or advantage of using broadcast vs signal is
>> to the application.
>
> It is completely visible to the application. Compare:
>
> "Ten threads have been woken up and are contending for the mutex in
> order the all return from their respective pthread_cond_wait calls."
>
> "One threads has been woken up and is contending for the mutex in
> order to return from pthread_cond_wait."

The thread is not contending for the mutex. Assuming the wakeup call was
done with the mutex unlocked, it'll just acquire it without contention
and without again having to enter the kernel and can just continue
running.

For the other case (assuming 1:1 threading) n, n > 1 threads sleeping in the
kernel are woken up, exit the kernel and contend for the mutex which
will cause n - 1 threads to immediately enter the kernel again and again go to
sleep there. That's not an issue on uniprocessors because only one of
these n threads can actually be running at any given time, hence, n - 1
end up on the runqueue and exit the kernel without contention on the
mutex one-by-one.

> Do you understand the api_ready example? Here it is again:

[...]

> If pthread_cond_signal is used, then quite likely, only one of those
> threads will wake up; the others will stay stuck forever.
>
> You can code this up and try it.

As demonstrated in another posting: This can be handled by maintaing a
counter of waiting threads and having the running thread wake up the
next one if there's still a thread waiting.

Rainer Weikusat <rweikusat@talktalk.net> writes:
>Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-02-07, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> Its also invisible to the application program so I still don't see
>>> what the difference and/or advantage of using broadcast vs signal is
>>> to the application.
>>
>> It is completely visible to the application. Compare:
>>
>> "Ten threads have been woken up and are contending for the mutex in
>> order the all return from their respective pthread_cond_wait calls."
>>
>> "One threads has been woken up and is contending for the mutex in
>> order to return from pthread_cond_wait."
>
>The thread is not contending for the mutex. Assuming the wakeup call was
>done with the mutex unlocked, it'll just acquire it without contention
>and without again having to enter the kernel and can just continue
>running.

The thread (and all other threads released by 'broadcast') will be
contending for the mutex. And it can't "acquire it without contention"
because they may be other threads, not currently waiting on the condition
variable, one of which may be holding the mutex.

scott@slp53.sl.home (Scott Lurndal) writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> On 2023-02-07, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>> Its also invisible to the application program so I still don't see
>>>> what the difference and/or advantage of using broadcast vs signal is
>>>> to the application.
>>>
>>> It is completely visible to the application. Compare:
>>>
>>> "Ten threads have been woken up and are contending for the mutex in
>>> order the all return from their respective pthread_cond_wait calls."
>>>
>>> "One threads has been woken up and is contending for the mutex in
>>> order to return from pthread_cond_wait."
>>
>>The thread is not contending for the mutex. Assuming the wakeup call was
>>done with the mutex unlocked, it'll just acquire it without contention
>>and without again having to enter the kernel and can just continue
>>running.
>
> The thread (and all other threads released by 'broadcast') will be
> contending for the mutex.

The paragraph I'm referring to obviously talks about pthread_cond_signal
("one thread has been woken up").

> And it can't "acquire it without contention"
> because they may be other threads, not currently waiting on the condition
> variable, one of which may be holding the mutex.

That's an act of God outside of the scope of this discussion.

Muttley@dastardlyhq.com, dans le message <trt6bs$3h5nq$1@dont-email.me>,
a écrit :
> How about explaining it then because I can't see it.

Consider a message queue with possibly multiple consumers.

If you add a message to the queue, you should call signal, because only one
consumer will be able to get your message.

If you mark the end of the queue, you should call broadcast, because all
consumers need to know the work is done.