Muttley@dastardlyhq.com, dans le message <ts58nd$11apa$1@dont-email.me>,
a écrit :
> it describes how broadcast differs from signal when it didn't say any such
> thing.

It says such a thing, but you are obviously deep into Dunning-Kruger
territory when it comes to threads.

Muttley@dastardlyhq.com writes:
> On Thu, 09 Feb 2023 17:37:15 +0000
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>Muttley@dastardlyhq.com writes:
>>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>>>Muttley@dastardlyhq.com writes:
>>
>>[...]
>>
>>>>>Clear would be:
>>>>>
>>>>>"Once the thread is woken up on the condition variable it then waits on
>>>>>the mutex AND DOES NOT EXIT pthread_cond_wait() until it aquires it."
>>>>>
>>>>>That is clarity, not the technogibberish above.
>>>>
>>>>The paragraph you call technogibberish has nothing to do with
>>>>what happens with the mutex, it's more of an internal implementation
>>>>detail and a warning to the implementer and the user of the effects of using
>>a
>>>>single
>>>>condition variable with different mutexes.
>>>>
>>>>This paragraph:
>>>>
>>>> Upon successful return, the mutex shall have been locked and
>>>> shall be owned by the calling thread.
>>>
>>> That also describe the behaviour with signal.
>>
>>Obviously, as the behaviour is identical in this regard.
>
> Exactly. So in trying to prove the man page was fine showed that even he
> hadn't read it properly.

Ehh ... no ... the implementation note is unrelated to this issue and
the difference between signal and broadcast is that the latter wakes up
all threads sleeping on the condition variable. As they must all acquire
the mutex before returning to the caller, it follows that they'll now
all be sleeping on the queue of that until each got its turn to hold
it.

On 10 Feb 2023 12:06:14 GMT
Nicolas George <nicolas$george@salle-s.org> wrote:
>Muttley@dastardlyhq.com, dans le message <ts58nd$11apa$1@dont-email.me>,
> a �crit�:
>> it describes how broadcast differs from signal when it didn't say any such
>> thing.
>
>It says such a thing, but you are obviously deep into Dunning-Kruger
>territory when it comes to threads.

Whatever. I'm certainly tired of this thread.

On 2023-02-07, Scott Lurndal <scott@slp53.sl.home> wrote:
> 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.

Well, it can; if the time spent in the mutex after the pthread_cond_wait
is very short, it could be that it's entirely uncontended.

On a single processor it could happen in an obvious way: only one thread
at a time runs. Several threads are made runnable by the broadcast.
One is at th ehead of the run queue. It acquires the mutex, returns from
pthread_cond_wait, does something in the mutex and then calls
pthread_mutex_unlock. Its time quantum is nowhere near up yet; the other
threads are still in the run queue. As they are dispatched by the
scheduler one by one, it's entirely possible they each find the mutex
similarly uncontended.

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

On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Wed, 08 Feb 2023 14:56:47 +0000
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>Muttley@dastardlyhq.com writes:
>>> I don't have time to write boilerplate to get this up and running but I
>>> can't see how using broadcast instead of signal makes any difference
>>> in how the code operates.
>>
>>As written, the code is correct with _broadcast and wouldn't be with
>>signal. Any number of threads can be waiting for the api to become
>>ready. Hence, whatever threads are actually waiting by that time must be
>>woken up as they'll otherwise sleep forever.
>
> Yes, they all get woken up then they all go back to sleep again except 1
> without doing anything. Sorry, still not seeing it.

No, threads woken up by pthread_cond_broadcast do not go back to sleep;
they all return from the pthread_cond_wait function. That function call has
a loop around it; so they will go back to sleep only if the loop
iterates again. The loop is guarded by the while (!api_ready) condition
which was set true before the pthread_cond_broadcast call, So all the
threads returning from the condition wait will see the true value and
bail out of the loop, returning from api_ready_wait.

The loop is is in the critical region protected by the mutex, so that
only one thread at a time can be checking while (!api_ready).
That's a separate consideration. "All threads return from
pthread_cond_wait" doesn't mean they do that concurrently; since a
thread returning from that function owns the mutex, all threads
returning from a condition wait against the same mutex are serialized.
Being serialized is not the same thing as being indefinitely blocked.

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

On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> If they're all sleeping on a mutex you don't need condition variables to
> start with.

1. condition varaibles exist because you can't do everything with mutexes.

2. the idea they are sleeping on the mutex is a simplification; it's
possible that the threads woken by the broadcast can each get the mutex
without waiting for it. This will happen on a single processor, if the
critical region is short:

E.g. here it is very short, just a few instructions:

while (!api_ready)
pthread_cond_wait(...)

pthread_mutex_unlock(...)

the returning thread acquires the mutex, examines api_ready,
finds it to be true, and immediately gives up the mutex.

You have to use multiple processors to get contention. On a single
processor, pthread_cond_broadcast will transfer all the waiting threads
to the run queue. The scheduler will then serialize their execution,
because only one thread can have the CPU at a time. So the first thread
gets the CPU, which may give it a time quantum of up to several
milliseconds or whatever. During that time quantum, it gets the mutex,
checks the flag and releases it. None of the other woken up threads
have yet executed, yet the first one is already done with the mutex;
it's returned out of api_ready_wait and has moved on to other work.
When the second thread is dispatched, it may well find the mutex
unlocked, and ditto with the third and subsequent.

> Whether you use signal or broadcast ONLY ONE thread exits the
> wait. The behaviour from an application program POV is identical.

If people are escaping from a burning a building, don't you think there
is a difference between "one person at a time jumps out of the window
onto the life net so they are all saved" versus "only one person manages
to jump out of the window to safety?"

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

On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> Nowhere have I read that inside pthread_cond_wait() there are 2
> possible thread states which you have to be aware of.

No, there aren't. Condition variablews are specifically stateless (or
appear that way to the application), which make them easy to use. You
don't have to think whether a condition variable is in some signalled
versus non-signalled state.

> What a bloody awful API design.

What is your proposal to fix it, or make an alternative?

Condition variables are directly derived from an invention called
"monitors and condition variables", by C. A. R. Hoare.
(Monitors and condition variables have some different properties
from POSIX-like mutexes and condition variables; there are certain
guarantees so that while loops are not required around condition waits.)

Anyway the API design comes more or less from the theory, which dictates
what it looks like.

Microsoft eventually added condition variables to Windows, and look,
the API is the same, under different names.

https://learn.microsoft.com/en-us/windows/win32/sync/condition-variables

If you think conditions are mutexes are complicated to use, you can use
something else. Conditions are very good for implementing other
kinds of primitives and being sure you got it right.

E.g. it's pretty trivial to make a correct counting semaphore with
a mutex and condition. The reverse isn't true; implementing conditions
with semaphores is a tricky exercise.

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

On Sat, 11 Feb 2023 06:30:46 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> On Wed, 08 Feb 2023 14:56:47 +0000
>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>Muttley@dastardlyhq.com writes:
>>>> I don't have time to write boilerplate to get this up and running but I
>>>> can't see how using broadcast instead of signal makes any difference
>>>> in how the code operates.
>>>
>>>As written, the code is correct with _broadcast and wouldn't be with
>>>signal. Any number of threads can be waiting for the api to become
>>>ready. Hence, whatever threads are actually waiting by that time must be
>>>woken up as they'll otherwise sleep forever.
>>
>> Yes, they all get woken up then they all go back to sleep again except 1
>> without doing anything. Sorry, still not seeing it.
>
>No, threads woken up by pthread_cond_broadcast do not go back to sleep;
>they all return from the pthread_cond_wait function. That function call has

No they don't all return, only 1 does.

Its interesting that hardly anyone really understands the difference between
the signal and broadcast and to me that is indicative of a very poorly designed
API.

On Sat, 11 Feb 2023 07:13:26 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> Nowhere have I read that inside pthread_cond_wait() there are 2
>> possible thread states which you have to be aware of.
>
>No, there aren't. Condition variablews are specifically stateless (or
>appear that way to the application), which make them easy to use. You

I meant the *function* has 2 states:
1) Waiting on the condition variable
2) Waiting on the mutex

It would seem that for signal only 1 thread goes from 1 -> 2 whereas with
broadcast ALL threads go from 1 -> 2 but only ONE thread exits the wait()
function in either case.

>don't have to think whether a condition variable is in some signalled
>versus non-signalled state.
>
>> What a bloody awful API design.
>
>What is your proposal to fix it, or make an alternative?

Apperently there is an alternative in pthreads someone mentioned called
barriers but its not mandatory and MacOS doesn't support them. However
they don't seem to have this 2 state locking nonsense.

>Condition variables are directly derived from an invention called
>"monitors and condition variables", by C. A. R. Hoare.
>(Monitors and condition variables have some different properties
>from POSIX-like mutexes and condition variables; there are certain
>guarantees so that while loops are not required around condition waits.)
>
>Anyway the API design comes more or less from the theory, which dictates
>what it looks like.

Thats the trouble with theories - they don't always translate into real world
use very well.

>E.g. it's pretty trivial to make a correct counting semaphore with
>a mutex and condition. The reverse isn't true; implementing conditions
>with semaphores is a tricky exercise.

SysV semaphores do a good job but the API is a mess.

On 11/02/2023 20:49, Muttley@dastardlyhq.com wrote:
> On Sat, 11 Feb 2023 06:30:46 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Wed, 08 Feb 2023 14:56:47 +0000
>>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>> Muttley@dastardlyhq.com writes:
>>>>> I don't have time to write boilerplate to get this up and running but I
>>>>> can't see how using broadcast instead of signal makes any difference
>>>>> in how the code operates.
>>>>
>>>> As written, the code is correct with _broadcast and wouldn't be with
>>>> signal. Any number of threads can be waiting for the api to become
>>>> ready. Hence, whatever threads are actually waiting by that time must be
>>>> woken up as they'll otherwise sleep forever.
>>>
>>> Yes, they all get woken up then they all go back to sleep again except 1
>>> without doing anything. Sorry, still not seeing it.
>>
>> No, threads woken up by pthread_cond_broadcast do not go back to sleep;
>> they all return from the pthread_cond_wait function. That function call has
>
> No they don't all return, only 1 does.
>
That does not tally with my experience.

What Operating System, programming language, and pthreads library are
you using? (You may have mentioned these things ages ago, I don't recall.)

> Its interesting that hardly anyone really understands the difference between
> the signal and broadcast and to me that is indicative of a very poorly designed
> API.
>
Well, those of us who have been using pthreads for a few decades seem to
have no trouble.

Cheers,
Gary B-)

On Sat, 11 Feb 2023 22:28:48 +1100
"Gary R. Schmidt" <grschmidt@acm.org> wrote:
>On 11/02/2023 20:49, Muttley@dastardlyhq.com wrote:
>> On Sat, 11 Feb 2023 06:30:46 -0000 (UTC)
>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>> On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>> On Wed, 08 Feb 2023 14:56:47 +0000
>>>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>> Muttley@dastardlyhq.com writes:
>>>>>> I don't have time to write boilerplate to get this up and running but I
>>>>>> can't see how using broadcast instead of signal makes any difference
>>>>>> in how the code operates.
>>>>>
>>>>> As written, the code is correct with _broadcast and wouldn't be with
>>>>> signal. Any number of threads can be waiting for the api to become
>>>>> ready. Hence, whatever threads are actually waiting by that time must be
>>>>> woken up as they'll otherwise sleep forever.
>>>>
>>>> Yes, they all get woken up then they all go back to sleep again except 1
>>>> without doing anything. Sorry, still not seeing it.
>>>
>>> No, threads woken up by pthread_cond_broadcast do not go back to sleep;
>>> they all return from the pthread_cond_wait function. That function call has
>>
>> No they don't all return, only 1 does.
>>
>That does not tally with my experience.

I don't believe you. If all threads exited the wait at the same time that
would mean they'd all acquired a lock on the same mutex at the same time.

>What Operating System, programming language, and pthreads library are
>you using? (You may have mentioned these things ages ago, I don't recall.)

MacOS.
>Well, those of us who have been using pthreads for a few decades seem to
>have no trouble.

I'd revisit the pthread_cond_wait man page if I were you.

Muttley@dastardlyhq.com writes:
>On Sat, 11 Feb 2023 22:28:48 +1100
>"Gary R. Schmidt" <grschmidt@acm.org> wrote:
>>On 11/02/2023 20:49, Muttley@dastardlyhq.com wrote:
>>> On Sat, 11 Feb 2023 06:30:46 -0000 (UTC)
>>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>> On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>>> On Wed, 08 Feb 2023 14:56:47 +0000
>>>>> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>>>> Muttley@dastardlyhq.com writes:
>>>>>>> I don't have time to write boilerplate to get this up and running but I
>>>>>>> can't see how using broadcast instead of signal makes any difference
>>>>>>> in how the code operates.
>>>>>>
>>>>>> As written, the code is correct with _broadcast and wouldn't be with
>>>>>> signal. Any number of threads can be waiting for the api to become
>>>>>> ready. Hence, whatever threads are actually waiting by that time must be
>>>>>> woken up as they'll otherwise sleep forever.
>>>>>
>>>>> Yes, they all get woken up then they all go back to sleep again except 1
>>>>> without doing anything. Sorry, still not seeing it.
>>>>
>>>> No, threads woken up by pthread_cond_broadcast do not go back to sleep;
>>>> they all return from the pthread_cond_wait function. That function call has
>>>
>>> No they don't all return, only 1 does.
>>>
>>That does not tally with my experience.
>
>I don't believe you. If all threads exited the wait at the same time that
>would mean they'd all acquired a lock on the same mutex at the same time.

Gary wrote that they exited the wait. By that, he was referring to
the internal implementation of pthread_cond_wait, he did not intend
to imply that the they returned from the pthread_cond_wait call;
clearly only one of the threads racing on the mutex will acquire
it, thus only one thread can return from pthread_cond_wait and
the remainder will wait for that thread to release the mutex
either explicitly or implicitly (e.g. calling pthread_cond_wait).

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> Nowhere have I read that inside pthread_cond_wait() there are 2
>> possible thread states which you have to be aware of.
>
>No, there aren't. Condition variablews are specifically stateless (or
>appear that way to the application), which make them easy to use. You
>don't have to think whether a condition variable is in some signalled
>versus non-signalled state.
>
>> What a bloody awful API design.
>
>What is your proposal to fix it, or make an alternative?
>
>Condition variables are directly derived from an invention called
>"monitors and condition variables", by C. A. R. Hoare.
>(Monitors and condition variables have some different properties
>from POSIX-like mutexes and condition variables; there are certain
>guarantees so that while loops are not required around condition waits.)

There was an early unix implementation of mutexes and condition
variables in Ultrix in the mid-80's when it added support for
multithreaded applications. Members of that team participated
heavily in the posix 1003.4 development that resulted in pthreads.

VMS on the other hand, used a more heavy-weight, but rather flexible
waiting mechanism called event flags, which Cutler brought over
when designing NT. The event flags interface allowed one to wait
on a set of events, rather than the single event that pthread condition
variables support.

Earlier mainframes had custom wait-for-event interfaces, such as
Burroughs complex wait (a more generalized version of the unix
poll(2) or select(2) system calls which allowed the application
to wait for a wide variety of events atomically, such as
I/O complete for a card reader, a timer, a message from another
application, input from a datacomm terminal, host-to-host
communications or a network packet.

Along with Hoare, was CSP (Cooperating Sequential Processes)
by Dykstra wherein he coined the term 'loosely connected processes',
or what we'd call today multithreaded processes and introduced
the concept of the semaphore as a synchronization primitive.

Then there were the distributed synchronization algorithms
espoused by Leslie Lamport (particularly with respect to
obtaining a consistent and rational view of time).

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD01xx/EWD123.html

On Sat, 11 Feb 2023 17:01:34 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>Condition variables are directly derived from an invention called
>>"monitors and condition variables", by C. A. R. Hoare.
>>(Monitors and condition variables have some different properties
>>from POSIX-like mutexes and condition variables; there are certain
>>guarantees so that while loops are not required around condition waits.)
>
>There was an early unix implementation of mutexes and condition
>variables in Ultrix in the mid-80's when it added support for
>multithreaded applications. Members of that team participated
>heavily in the posix 1003.4 development that resulted in pthreads.
>
>VMS on the other hand, used a more heavy-weight, but rather flexible
>waiting mechanism called event flags, which Cutler brought over
>when designing NT. The event flags interface allowed one to wait

Shame he didn't port VMS's reliability too.

On 2023-02-11, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Sat, 11 Feb 2023 06:30:46 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>No, threads woken up by pthread_cond_broadcast do not go back to sleep;
>>they all return from the pthread_cond_wait function. That function call has
>
> No they don't all return, only 1 does.

They all return, just not at the same time. Obviously, if the first
thread which returns does something unusual, like never unlocking the
mutex, then the others are stuck. That's almost certainly going to only
happen due to a bug.

I have the impression you are just trying to rearrange the verbal
expressions of concepts instead of thinking in terms of the actual
concurrency.

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

On 2023-02-11, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Sat, 11 Feb 2023 07:13:26 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> Nowhere have I read that inside pthread_cond_wait() there are 2
>>> possible thread states which you have to be aware of.
>>
>>No, there aren't. Condition variablews are specifically stateless (or
>>appear that way to the application), which make them easy to use. You
>
> I meant the *function* has 2 states:
> 1) Waiting on the condition variable
> 2) Waiting on the mutex

Such states are not externally observable. There is literally no
standard API by which you can tell, and application logic isn't
required to handle any such states.

> It would seem that for signal only 1 thread goes from 1 -> 2 whereas with
> broadcast ALL threads go from 1 -> 2 but only ONE thread exits the wait()
> function in either case.

That is not the proper understanding. Whether (2) waiting on the mutex
happens is a matter of chance: it depends on factors like how many
processors are there, and how long is the mutex being held.

All those threads will go through the mutex, taking turns owning it; but
that doesn't imply they were ever waiting on it. Mutex locks can be
acquired without waiting.

>>don't have to think whether a condition variable is in some signalled
>>versus non-signalled state.
>>
>>> What a bloody awful API design.
>>
>>What is your proposal to fix it, or make an alternative?
>
> Apperently there is an alternative in pthreads someone mentioned called

That was me.

> barriers but its not mandatory and MacOS doesn't support them.

That's pretty lame; I wrote the first glibc/linux version of
pthread_barrier_wait in 2001, now 22 years ago. Kids born then
are graduating with degrees.

Be that as it may, you can quite easily make barriers if you have
mutexes/conditions. A program depending on pthread_barrier_wait can
easily supply its own implementation to be ported to a system where that
is missing.

Barriers are not an alternative to conditions.

> However they don't seem to have this 2 state locking nonsense.

Barriers are also not useful in many situations in which conditions
are. They have their own limitations. You have to declare how many
threads are using a barrier. When that many threads wait on it, the
barrier triggers, letting them all go. One of the threads is selected
(perhaps randomly) as the "serial thread": it receives a different
return value informing it.

This is useful for parallel processing scenarios, where you have all the
threads doing some portion of the same overall task, like some sort
of parallelized number crunching.

>>E.g. it's pretty trivial to make a correct counting semaphore with
>>a mutex and condition. The reverse isn't true; implementing conditions
>>with semaphores is a tricky exercise.
>
> SysV semaphores do a good job but the API is a mess.

Good job of what? Implementing condition variables?

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

On Sun, 12 Feb 2023 05:35:48 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-02-11, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> On Sat, 11 Feb 2023 06:30:46 -0000 (UTC)
>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>No, threads woken up by pthread_cond_broadcast do not go back to sleep;
>>>they all return from the pthread_cond_wait function. That function call has
>>
>> No they don't all return, only 1 does.
>
>They all return, just not at the same time. Obviously, if the first
>thread which returns does something unusual, like never unlocking the
>mutex, then the others are stuck. That's almost certainly going to only
>happen due to a bug.

Why is it a bug? It may be a long time before the first exiting the wait
unlocks the mutex depending on what the program does. The fact remains that
only one thread exits the wait at a time regardless of whether you send a
signal or broadcast. The disctinction in the behaviour is confusing and IMO
its a poorly designed API. For a start if all you want to do is control
threads stopping and starting without potentially having a deadlock with the
controlling thread there's no need to use mutexes in the first place.

On Sun, 12 Feb 2023 06:27:07 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>On 2023-02-11, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> On Sat, 11 Feb 2023 07:13:26 -0000 (UTC)
>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>> Nowhere have I read that inside pthread_cond_wait() there are 2
>>>> possible thread states which you have to be aware of.
>>>
>>>No, there aren't. Condition variablews are specifically stateless (or
>>>appear that way to the application), which make them easy to use. You
>>
>> I meant the *function* has 2 states:
>> 1) Waiting on the condition variable
>> 2) Waiting on the mutex
>
>Such states are not externally observable. There is literally no
>standard API by which you can tell, and application logic isn't
>required to handle any such states.

No, but the application logic has to be different depending on whether you're
using signal or broadcast.

>> It would seem that for signal only 1 thread goes from 1 -> 2 whereas with
>> broadcast ALL threads go from 1 -> 2 but only ONE thread exits the wait()
>> function in either case.
>
>That is not the proper understanding. Whether (2) waiting on the mutex
>happens is a matter of chance: it depends on factors like how many
>processors are there, and how long is the mutex being held.

If the API behaves differently depending on the hardware core count then
frankly its a POS and shouldn't be used.

>> barriers but its not mandatory and MacOS doesn't support them.
>
>That's pretty lame; I wrote the first glibc/linux version of
>pthread_barrier_wait in 2001, now 22 years ago. Kids born then
>are graduating with degrees.

Yeah well, Apple. They tend to suffer from NIH syndrome quite badly. I guess
I'm lucky they support pthreads at all.

>Be that as it may, you can quite easily make barriers if you have
>mutexes/conditions. A program depending on pthread_barrier_wait can
>easily supply its own implementation to be ported to a system where that
>is missing.

Lifes too short.

>> SysV semaphores do a good job but the API is a mess.
>
>Good job of what? Implementing condition variables?

Gatekeeping critical code sections in seperate processes (not sure about
threads, are they thread safe?).

Muttley@dastardlyhq.com writes:
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>On 2023-02-11, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Sat, 11 Feb 2023 07:13:26 -0000 (UTC)
>>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>>On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>>> Nowhere have I read that inside pthread_cond_wait() there are 2
>>>>> possible thread states which you have to be aware of.
>>>>
>>>>No, there aren't. Condition variablews are specifically stateless (or
>>>>appear that way to the application), which make them easy to use. You
>>>
>>> I meant the *function* has 2 states:
>>> 1) Waiting on the condition variable
>>> 2) Waiting on the mutex
>>
>>Such states are not externally observable. There is literally no
>>standard API by which you can tell, and application logic isn't
>>required to handle any such states.
>
> No, but the application logic has to be different depending on whether you're
> using signal or broadcast.

One would assume that different applications use either broadcast or
signal, depending on what the intended use of the condition variable
is.

>>> It would seem that for signal only 1 thread goes from 1 -> 2 whereas with
>>> broadcast ALL threads go from 1 -> 2 but only ONE thread exits the wait()
>>> function in either case.
>>
>>That is not the proper understanding. Whether (2) waiting on the mutex
>>happens is a matter of chance: it depends on factors like how many
>>processors are there, and how long is the mutex being held.
>
> If the API behaves differently depending on the hardware core count then
> frankly its a POS and shouldn't be used.

The API doesn't behave differently. The behaviour of the implementation
depends partially on the hardware. It also depends on the available
system facilities. Eg, on Linux, there's a FUTEX_CMP_REQUEUE operation
which can be used to implement pthread_cond_broadcast more efficiently
than a naive implementation: Assuming more than one thread is sleeping
on the condition variable, a single syscall can be used to wake up n
threads (usually 1) and move the remaining ones to the queue of the
mutex would the wake up, exit kernel, test lock, enter kernel, sleep
dance.

Muttley@dastardlyhq.com writes:
> On Sun, 12 Feb 2023 05:35:48 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>On 2023-02-11, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Sat, 11 Feb 2023 06:30:46 -0000 (UTC)
>>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>>No, threads woken up by pthread_cond_broadcast do not go back to sleep;
>>>>they all return from the pthread_cond_wait function. That function call has
>>>
>>> No they don't all return, only 1 does.
>>
>>They all return, just not at the same time. Obviously, if the first
>>thread which returns does something unusual, like never unlocking the
>>mutex, then the others are stuck. That's almost certainly going to only
>>happen due to a bug.
>
> Why is it a bug? It may be a long time before the first exiting the wait
> unlocks the mutex depending on what the program does. The fact remains that
> only one thread exits the wait at a time regardless of whether you send a
> signal or broadcast. The disctinction in the behaviour is confusing and IMO
> its a poorly designed API. For a start if all you want to do is control
> threads stopping and starting without potentially having a deadlock with the
> controlling thread there's no need to use mutexes in the first place.

But that's not what a condition variable is supposed to be good for. The
idea behind that is that there's some shared state, eg, head and tail/
chain pointers for queue different threads need to work with. Hence, a
mutex is needed to serialize access to this state. The simple example is
a set of consumer threads consuming work items produced by a set of
producer threads. A producer thread does the following:

1. Lock the mutex.
2. Put a work item on the queue.
3. Unlock the mutex.
4. Broacast on the condition variable to wake up sleeping consumer
threads.

Consumer thread:

1. Lock the mutex.
2. Work to do? If so, goto 5
3. Sleep on condvar.
4. Goto 2.
5. Take work item off the queue.
6. Unlock the mutex.

On 2023-02-12, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Sun, 12 Feb 2023 05:35:48 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>On 2023-02-11, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Sat, 11 Feb 2023 06:30:46 -0000 (UTC)
>>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>>No, threads woken up by pthread_cond_broadcast do not go back to sleep;
>>>>they all return from the pthread_cond_wait function. That function call has
>>>
>>> No they don't all return, only 1 does.
>>
>>They all return, just not at the same time. Obviously, if the first
>>thread which returns does something unusual, like never unlocking the
>>mutex, then the others are stuck. That's almost certainly going to only
>>happen due to a bug.
>
> Why is it a bug? It may be a long time before the first exiting the wait
> unlocks the mutex depending on what the program does.

It may or may not.

The point is that all the threads that were waiting on the condition are
no longer waiting on it; they are waiting to return from the funtion,
which is subject to being serialized.

Like people who got their burgers from the fast food restaurant, which
are just passing through the exit door. They are not waiting for
burgers, just their turn to exit.

Now imagine there was some situation like "restaurant on fire". That
condition has to be broadcast: everyone leave! The customers stop
waiting for burgers and head for the door. They still can't pass through
it at the same time; one person emerges at a time.

> The fact remains that
> only one thread exits the wait at a time regardless of whether you send a
> signal or broadcast.

The fact remains that only one person leaves the burger joint, whether
or not you sound a fire alarm telling them all to leave, or whether
a single burger order was just filled, and the other customers are still
waiting for theirs.

> The disctinction in the behaviour is confusing and IMO
> its a poorly designed API.

Not to anyone who understands burger joints, doors and fire alarms.

> For a start if all you want to do is control
> threads stopping and starting without potentially having a deadlock with the
> controlling thread there's no need to use mutexes in the first place.

Controlling the starting and stopping of another thread is fraught with
race conditions. Pretty much only two kinds of applications do this:
debuggers, and stop-the-world garbage collectors.

You cannot use that for everyday synchronization.

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

On 2023-02-12, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Sun, 12 Feb 2023 06:27:07 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>On 2023-02-11, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>> On Sat, 11 Feb 2023 07:13:26 -0000 (UTC)
>>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>>On 2023-02-08, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>>>> Nowhere have I read that inside pthread_cond_wait() there are 2
>>>>> possible thread states which you have to be aware of.
>>>>
>>>>No, there aren't. Condition variablews are specifically stateless (or
>>>>appear that way to the application), which make them easy to use. You
>>>
>>> I meant the *function* has 2 states:
>>> 1) Waiting on the condition variable
>>> 2) Waiting on the mutex
>>
>>Such states are not externally observable. There is literally no
>>standard API by which you can tell, and application logic isn't
>>required to handle any such states.
>
> No, but the application logic has to be different depending on whether you're
> using signal or broadcast.

Umm, not really. Mostly, you just have to avoid using signal when the
logic calls for brodcast, and use broadcast.

If you need broadcast, but insist on using signal, then your application
logic has to be different --- because the code as-is will not work with
signal. You have to somehow emulate the behavior of broadcast.

Rainer W. pointed this out in a reasponse to the api_ready example:
there is a way to code it without broadcast with additional logic,
involving signal being called multiple times.

We can work this back into the burger joint example. Signal is used
to indicate that a customer's order is ready. If the place is on fire,
that situation is broadcast, so everyone leaves.

Suppose you don't broadcast the "fire" signal, but still want to get
everyone to leave? You can do it like this: signal one person to leave
the building. When they exit, /they/ turn around and signal again,
causing the next person inside to exit. This repeats until the last
person leaves. When the last person signals into the building, there is
nobody left there so the signal is ignored. (If the building maitains a
count how of many people are in it, this wasteful last signal can be
avoided.)

This is simply a simulation of broadcast, which distributes the
responsibility among the threads.

>>> It would seem that for signal only 1 thread goes from 1 -> 2 whereas with
>>> broadcast ALL threads go from 1 -> 2 but only ONE thread exits the wait()
>>> function in either case.
>>
>>That is not the proper understanding. Whether (2) waiting on the mutex
>>happens is a matter of chance: it depends on factors like how many
>>processors are there, and how long is the mutex being held.
>
> If the API behaves differently depending on the hardware core count then
> frankly its a POS and shouldn't be used.

Anything with threads behaves differently based on OS platform and
its scheduling, number of cores, system load, tuning parameters, CPU
model, ...

If the application has any dependency on the execution order of pieces
of logic on different threads, then it has to ensure that somehow;
otherwise it's just depending on that by fluke.

It's possible for mutexes and ocnditions to provide stronger guarantees
about certain behaviors. For instance we can have Hoare semantics,
whereby the signaler atomically transfers a waiting thread into the
mutex, and is then guaranteed to immediately get the mutex back when
that thread is done (no matter who else wants the mutex in the
meanwhile). Hoare's semantics make it easier to prove the correctness of
some programs --- but are awful for implementing the stuff on a modern
multiprocessor, in terms of performance.

There is a tradeoff between enforcing orders---who gets the mutex in
what order, and what not---and performance. Enforcing orders introduces
overhead. Potentially huge overhead. Because you run into situations
like, for instance, a thread currently running on a processor being
primed and ready to seize a mutex, do something quick and release it,
but being prevented from doing that because some other thread is
supposed to get that mutex first. Wasteful context switching occurs.
The threads involved execute hundreds, or thousands of unnecessary
instructions.

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

On Tue, 14 Feb 2023 02:46:45 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> For a start if all you want to do is control
>> threads stopping and starting without potentially having a deadlock with the
>> controlling thread there's no need to use mutexes in the first place.
>
>Controlling the starting and stopping of another thread is fraught with
>race conditions. Pretty much only two kinds of applications do this:
>debuggers, and stop-the-world garbage collectors.
>
>You cannot use that for everyday synchronization.

Nonsense. What do you think spinlocks are for?

On 2023-02-14, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
> On Tue, 14 Feb 2023 02:46:45 -0000 (UTC)
> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>> For a start if all you want to do is control
>>> threads stopping and starting without potentially having a deadlock with the
>>> controlling thread there's no need to use mutexes in the first place.
>>
>>Controlling the starting and stopping of another thread is fraught with
>>race conditions. Pretty much only two kinds of applications do this:
>>debuggers, and stop-the-world garbage collectors.
>>
>>You cannot use that for everyday synchronization.
>
> Nonsense. What do you think spinlocks are for?

Mainly, I think that spinlocks are not an example of one thread
controlling (stopping, starting) the execution of another, so they
are unrelated to my remarks.

Spinlocks are a kind of mutex. They are acquired and released, and
understood to be held by a thread (or other context).

Deadlocks are possible with spinlocks, just as with mutexes.
For instance, two threads both try to acquire a pair of spinlocks,
but in opposite order.

--
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-14, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>> On Tue, 14 Feb 2023 02:46:45 -0000 (UTC)
>> Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>>>> For a start if all you want to do is control
>>>> threads stopping and starting without potentially having a deadlock with the
>>>> controlling thread there's no need to use mutexes in the first place.
>>>
>>>Controlling the starting and stopping of another thread is fraught with
>>>race conditions. Pretty much only two kinds of applications do this:
>>>debuggers, and stop-the-world garbage collectors.
>>>
>>>You cannot use that for everyday synchronization.
>>
>> Nonsense. What do you think spinlocks are for?
>
>Mainly, I think that spinlocks are not an example of one thread
>controlling (stopping, starting) the execution of another, so they
>are unrelated to my remarks.
>
>Spinlocks are a kind of mutex. They are acquired and released, and
>understood to be held by a thread (or other context).
>
>Deadlocks are possible with spinlocks, just as with mutexes.
>For instance, two threads both try to acquire a pair of spinlocks,
>but in opposite order.

Although to be fair, you can use a spinlock as a sort of condition
variable in cases where:
1) there will only be one waiter and you want signal semantics
2) there may be multiple waiters and you want broadcast semantics
3) you don't care that a core will be spinning while waiting.

More suitable for coordinating between supervisory software
on an SMP processor (i.e. a bare metal hypervisor).

/**
* Initialize the condition variable to a unsignalled state.
*/
inline void
c_condition::init(void)
{ condition = 0;
timedout = 0;
}

/**
* Wait for condition state to be signalled. The waiter is awakened by
* the c_condition::signal() function setting the c_condition::condition
* value to 1.
*/
inline void
c_condition::wait(void)
{ __asm__ __volatile__ (
"\n1:\t"
"testl $0xffffffff, %0\n\t"
"jnz 2f\n\t"
"xorq %%rcx, %%rcx\n\t"
"xorq %%rdx, %%rdx\n\t"
"leaq %0, %%rax\n\t"
"monitor\n\t"
"testl $0xffffffff, %0\n\t"
"jnz 2f\n\t"
"xorq %%rax, %%rax\n\t"
"mwait\n\t"
"jmp 1b\n\t"
"2:\n\t"
"movl $0, %0\n\t"
:
: "m"(condition)
: "memory", "ax", "cx", "dx");
}

/**
* Signal condition. Implemented by setting the condition value to 1.
*/
inline void
c_condition::signal(void)
{ __asm__ __volatile__ ("movl $1, %0": "=m" (condition): : "memory");
}

/**
* Condition variable with timeout semantics. Wait for the condition
* to be signalled, or a specified timeout to elapse. Returns 'true'
* if the timeout fired.
*
* @param ns The number of nanoseconds to wait.
* @returns true if the wait was satisfied, false if the timer fired.
*/
bool
c_condition::timed_wait(uint64 ns)
{ timedout = 0;
c_timer *to = new c_timer(c_timer::ONESHOT,
c_core::get_current()->get_current_time() + ns, this);

wait();

delete to;
return (timedout == 0);
}

/**
* Callback function for condition variable timer expiration.
*
* @param arg Callback argument, unused.
*/
void
c_condition::timer_callback(void *arg)
{ timedout = 1;
signal();
}

/**
* Wait for condition state to be signalled. The waiter is awakened by
* the c_condition::signal() function setting the c_condition::condition
* value to 1 and intermitantly it wakes up and processes any pending defered
* tasks.
*/
void
c_condition::wait_run_defer(void)
{ c_core *cp = c_core::get_current();

while (condition == 0) {
cp->delay(MICROSECONDS(1));
// Handle deferred work
cp->get_dispatcher()->intercept();
}
condition = 0;
}

/**
* Condition variable with timeout semantics. Wait for the condition
* to be signalled, or a specified timeout to elapse. This function
* intermittently wakes up and processes any pending deferred tasks.
*
* @param ns The number of nanoseconds to wait.
* @returns true if the wait was satisfied, false if the timer fired.
*/
bool
c_condition::timed_wait_run_defer(uint64 ns)
{ timedout = 0;
c_timer *to = new c_timer(c_timer::ONESHOT,
c_core::get_current()->get_current_time() + ns, this);

wait_run_defer();

delete to;
return (timedout == 0);
}

/* vim: sw=4 sts=4 sta ts=8:
*/