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
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?
Far too complex to be helpful.
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 <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.
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.
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 <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 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?
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?
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);
pthread_mutex_ulock(&api_mutex);if (more) pthread_cond_signal(&api_cond);
}pthread_cond_signal(&api_cond);
void api_ready()
{
pthread_mutex_lock(&api_mutex);
api_ready = true;
pthread_mutex_ulock(&api_mutex);
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?
On 06/02/2023 20:19, Muttley@dastardlyhq.com wrote:
Even though I've been doing threads programming for years I've alwaysWhat I was told, a couple of decades ago, was that _signal meant that >(usually/mostly/maybe/probably) only one thread waiting on that signal
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?
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. :-)
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 alwaysWhat 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.))
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?
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 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 alwaysWhat 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
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?
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.
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.
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
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.
If multiple threads exited the wait then that would be a useful paradigm
but AFAIK pthreads doesn't supply that functionality.
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
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.
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.
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:
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.
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.
How about explaining it then because I can't see it.
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.
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.
On Tue, 7 Feb 2023 19:33:41 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
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
}
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.
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.
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.
Muttley@dastardlyhq.com writes:
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.
But the will be sleeping on the mutex, not the condition variable
at that point. A far different sleep entirely.
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.
Muttley@dastardlyhq.com writes:
If they're all sleeping on a mutex you don't need condition variables to >>start with. Whether you use signal or broadcast ONLY ONE thread exits the >>wait. The behaviour from an application program POV is identical.
No, when you use broadcast, _all_ threads exit the wait for the event
and start waiting for the mutex. Subsequently, as each thread gets
the mutex, does something in the critical region, then releases
the mutex, the remaining threads will contend for mutex, perform
the critical region and release the mutex. They won't be still waiting
on the condition variable until each thread calls pthread_cond_wait* again.
The difference between signal and broadcast is _what_ the remaining
threads end up waiting for. In the former, the remaining threads
continue to wait on the condition variable; in the latter the
remaining threads contend for the mutex protecting the resource/critical >section.
On Wed, 08 Feb 2023 16:02:02 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
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.
But the will be sleeping on the mutex, not the condition variable
at that point. A far different sleep entirely.
If they're all sleeping on a mutex you don't need condition variables to start with.
Whether you use signal or broadcast ONLY ONE thread exits the
wait. The behaviour from an application program POV is identical.
On Wed, 08 Feb 2023 16:02:02 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
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.
But the will be sleeping on the mutex, not the condition variable
at that point. A far different sleep entirely.
If they're all sleeping on a mutex you don't need condition variables to >start with. Whether you use signal or broadcast ONLY ONE thread exits the >wait. The behaviour from an application program POV is identical.
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.
Muttley@dastardlyhq.com writes:
On Wed, 08 Feb 2023 16:36:56 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
If they're all sleeping on a mutex you don't need condition variables to >>>>start with. Whether you use signal or broadcast ONLY ONE thread exits the >>>>wait. The behaviour from an application program POV is identical.
No, when you use broadcast, _all_ threads exit the wait for the event
and start waiting for the mutex. Subsequently, as each thread gets
the mutex, does something in the critical region, then releases
the mutex, the remaining threads will contend for mutex, perform
the critical region and release the mutex. They won't be still waiting >>>on the condition variable until each thread calls pthread_cond_wait* again. >>>
The difference between signal and broadcast is _what_ the remaining >>>threads end up waiting for. In the former, the remaining threads >>>continue to wait on the condition variable; in the latter the
remaining threads contend for the mutex protecting the resource/critical >>>section.
Ok, someone finally explained it in a comprehensible way. Thanks.
Nowhere have I read that inside pthread_cond_wait() there are 2 possible >thread
states which you have to be aware of. What a bloody awful API design.
This seems pretty clear to me:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_wait.ht
ml
On Wed, 08 Feb 2023 16:36:56 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Muttley@dastardlyhq.com writes:
If they're all sleeping on a mutex you don't need condition variables to >>>start with. Whether you use signal or broadcast ONLY ONE thread exits the >>>wait. The behaviour from an application program POV is identical.
No, when you use broadcast, _all_ threads exit the wait for the event
and start waiting for the mutex. Subsequently, as each thread gets
the mutex, does something in the critical region, then releases
the mutex, the remaining threads will contend for mutex, perform
the critical region and release the mutex. They won't be still waiting
on the condition variable until each thread calls pthread_cond_wait* again. >>
The difference between signal and broadcast is _what_ the remaining
threads end up waiting for. In the former, the remaining threads
continue to wait on the condition variable; in the latter the
remaining threads contend for the mutex protecting the resource/critical >>section.
Ok, someone finally explained it in a comprehensible way. Thanks.
Nowhere have I read that inside pthread_cond_wait() there are 2 possible thread
states which you have to be aware of. What a bloody awful API design.
"Once all waiting threads have been unblocked (as by the pthread_cond_broadcast() operation), the next wait operation on that condition
variable shall form a new dynamic binding with the mutex specified by that wait
operation. Even though the dynamic binding between condition variable and mutex
may be removed or replaced between the time a thread is unblocked from a wait on
the condition variable blah blah blah ....."
I'm not sure what your definition of "clear" is but its obviously very different
to mine.
This seems pretty clear to me:
Scott Lurndal, dans le message <aHQEL.430433$gGD7.95617@fx11.iad>, a
écrit :
This seems pretty clear to me:
Not only is it clear, but it is also entirely natural. Once you have threads >of the kind of POSIX threads and mutexes, if you think what API you need to >implement the kind of things conditions are for, and then you compare with >what conditions actually do, your solution is usually more or less the same, >but the condition API is sleeker.
Nicolas George <nicolas$george@salle-s.org> writes:
Scott Lurndal, dans le message <aHQEL.430433$gGD7.95617@fx11.iad>, a
écrit :
This seems pretty clear to me:
Not only is it clear, but it is also entirely natural. Once you have threads >>of the kind of POSIX threads and mutexes, if you think what API you need to >>implement the kind of things conditions are for, and then you compare with >>what conditions actually do, your solution is usually more or less the same, >>but the condition API is sleeker.
Indeed. It is rather similar to the hardware-based mutual exclusion
and event (condition) mechanism we invented for a Burroughs mainframe
around 1982. The LOK instruction was implemented in hardware, OS (MCP)
Muttley@dastardlyhq.com writes:
[...]
"Once all waiting threads have been unblocked (as by the
pthread_cond_broadcast() operation), the next wait operation on that >condition
variable shall form a new dynamic binding with the mutex specified by that >wait
operation. Even though the dynamic binding between condition variable and >mutex
may be removed or replaced between the time a thread is unblocked from a >wait on
the condition variable blah blah blah ....."
I'm not sure what your definition of "clear" is but its obviously very >different
to mine.
This seems clear to me: Assuming a condition variable c is initially
idle, ie, there are not threads waiting on in, the mutex m used in the
first call to pthread_cond_wait on c must be recorded somewhere to
enable woken-up threads to acquire the correct mutex. A new mutex mm can be >associated with c once all threads sleeping on c+m have been woken up. But >this shall not affect threads which haven't yet returned to the caller
which slept on c while it was still associated with m.
On Wed, 08 Feb 2023 21:11:18 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Nicolas George <nicolas$george@salle-s.org> writes:
Scott Lurndal, dans le message <aHQEL.430433$gGD7.95617@fx11.iad>, a
écrit :
This seems pretty clear to me:
Not only is it clear, but it is also entirely natural. Once you have threads >>>of the kind of POSIX threads and mutexes, if you think what API you need to >>>implement the kind of things conditions are for, and then you compare with >>>what conditions actually do, your solution is usually more or less the same, >>>but the condition API is sleeker.
Indeed. It is rather similar to the hardware-based mutual exclusion
and event (condition) mechanism we invented for a Burroughs mainframe >>around 1982. The LOK instruction was implemented in hardware, OS (MCP)
Did the Tron scriptwriters nick the MCP acronym from you or you from them? :)
On Wed, 08 Feb 2023 17:32:01 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Muttley@dastardlyhq.com writes:
[...]
"Once all waiting threads have been unblocked (as by the
pthread_cond_broadcast() operation), the next wait operation on that >>condition
variable shall form a new dynamic binding with the mutex specified by that >>wait
operation. Even though the dynamic binding between condition variable and >>mutex
may be removed or replaced between the time a thread is unblocked from a >>wait on
the condition variable blah blah blah ....."
I'm not sure what your definition of "clear" is but its obviously very >>different
to mine.
This seems clear to me: Assuming a condition variable c is initially
idle, ie, there are not threads waiting on in, the mutex m used in the >>first call to pthread_cond_wait on c must be recorded somewhere to
enable woken-up threads to acquire the correct mutex. A new mutex mm can be >>associated with c once all threads sleeping on c+m have been woken up. But >>this shall not affect threads which haven't yet returned to the caller >>which slept on c while it was still associated with m.
No.
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.
Muttley@dastardlyhq.com writes:
On Wed, 08 Feb 2023 17:32:01 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Muttley@dastardlyhq.com writes:
[...]
"Once all waiting threads have been unblocked (as by the
pthread_cond_broadcast() operation), the next wait operation on that >>>condition
variable shall form a new dynamic binding with the mutex specified by that >>>wait
operation. Even though the dynamic binding between condition variable and >>>mutex
may be removed or replaced between the time a thread is unblocked from a >>>wait on
the condition variable blah blah blah ....."
I'm not sure what your definition of "clear" is but its obviously very >>>different
to mine.
This seems clear to me: Assuming a condition variable c is initially >>>idle, ie, there are not threads waiting on in, the mutex m used in the >>>first call to pthread_cond_wait on c must be recorded somewhere to
enable woken-up threads to acquire the correct mutex. A new mutex mm can be >>>associated with c once all threads sleeping on c+m have been woken up. But >>>this shall not affect threads which haven't yet returned to the caller >>>which slept on c while it was still associated with m.
No.
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.
Is clear and states exactly what you said "clear would be" above.
On Wed, 08 Feb 2023 17:32:01 +0000
Rainer Weikusat <rweikusat@talktalk.net> wrote:
Muttley@dastardlyhq.com writes:
[...]
"Once all waiting threads have been unblocked (as by the
pthread_cond_broadcast() operation), the next wait operation on that >>condition
variable shall form a new dynamic binding with the mutex specified by that >>wait
operation. Even though the dynamic binding between condition variable and >>mutex
may be removed or replaced between the time a thread is unblocked from a >>wait on
the condition variable blah blah blah ....."
I'm not sure what your definition of "clear" is but its obviously very >>different
to mine.
This seems clear to me: Assuming a condition variable c is initially
idle, ie, there are not threads waiting on in, the mutex m used in the >>first call to pthread_cond_wait on c must be recorded somewhere to
enable woken-up threads to acquire the correct mutex. A new mutex mm can be >>associated with c once all threads sleeping on c+m have been woken up. But >>this shall not affect threads which haven't yet returned to the caller >>which slept on c while it was still associated with m.
No.
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.
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.
Muttley@dastardlyhq.com, dans le message <ts55k0$10vn2$1@dont-email.me>,
a écrit :
^^^^^^^^^^^^^^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.
You are the one who is not reading properly in this whole thread.
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.
it describes how broadcast differs from signal when it didn't say any such thing.
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:
[...]
aClear 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
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.
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.
Nowhere have I read that inside pthread_cond_wait() there are 2
possible thread states which you have to be aware of.
What a bloody awful API design.
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.
If they're all sleeping on a mutex you don't need condition variables to start with.
Whether you use signal or broadcast ONLY ONE thread exits the
wait. The behaviour from an application program POV is identical.
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.
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
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.
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.
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 11/02/2023 20:49, Muttley@dastardlyhq.com wrote:
On Sat, 11 Feb 2023 06:30:46 -0000 (UTC)That does not tally with my experience.
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 +0000No they don't all return, only 1 does.
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 >>
What Operating System, programming language, and pthreads library are
you using? (You may have mentioned these things ages ago, I don't recall.)
Well, those of us who have been using pthreads for a few decades seem to
have no trouble.
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.)
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)That does not tally with my experience.
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.
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.
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
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.
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.
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 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.
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.
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.
SysV semaphores do a good job but the API is a mess.
Good job of what? Implementing condition variables?
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.
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.
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.
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.
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.
delay(MICROSECONDS(1));// Handle deferred work
get_dispatcher()->intercept();}
Kaz Kylheku <864-117-4973@kylheku.com> writes:
/**
* 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");
}
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 489 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 34:15:52 |
| Calls: | 9,668 |
| Calls today: | 3 |
| Files: | 13,716 |
| Messages: | 6,169,127 |