On Tue, 7 Feb 2023 19:04:59 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>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.

Err yes, and you can't use condition variables without a mutex so I'm not
sure what your point is.

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

I know. And? How does that change the functionality from the POV of the
application code?

>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.

That makes no sense. Either a thread is waiting in pthread_cond_wait() or it
isn't. If it isn't then its irrelevant to this discussion.

>> 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.

Ok, didn't know about that. However it appears to be optional not mandatory
and MacOS doesn't support it so not much use for truly portable code.

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
> }
>
> 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.

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.

Muttley@dastardlyhq.com writes:
> 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.

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.

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.

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.

Muttley@dastardlyhq.com writes:
>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.
>

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.

Muttley@dastardlyhq.com writes:
> 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.

Without broadcast, only one thread sleeping on the queue of the
condition variable would ever be woken up. All others would remain
sleeping there forever. If they're instead sleeping the queue of the
mutex, they'd eventually all be woken up due to mutex unlock operations.

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.

Muttley@dastardlyhq.com writes:
> 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.

A locked mutex has an owner and implementations may throw an error if a
thread other than the one which owns the mutex tries to unlock it (NPTL
does). Condition variables can be signalled by any thread.

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

.... until this one thread unlocks the mutex. If broadcast had been used
on the condition variable, another thread originally sleeping on that
will now start to run. Otherwise, the outcome is an unlocked mutex and a set
of threads still sleeping on something else.

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.html

On Wed, 08 Feb 2023 17:09:26 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>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

"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.

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.

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)
scheduling was performed in a microkernel that handled all interrupts
and scheduled the highest priority ready task (and very little else other
than timers). The MCP ran at a slightly less privileged level when
processing "system calls" on behalf of a user task (known as Branch Communicate,
i.e. the BCT instruction). The main difference with POSIX is the atomic
releasing of the mutex during the condition wait function.

===== Lock/Unlock (LOK)/OP=60 =====

==== Format ====

^ OP ^ AF ^ BF ^ A Syllable ^

''OP = 60''

**AF** Unused and reserved; can be specified as an indirect field length. A literal flag causes an invalid instruction fault (IEX = 21).\\
**BF** Instruction variant; can be indirect.

^ Variant ^ Function ^
| 10 | Event cause no interrupt |
| 09 | Event cause and reset |
| 08 | Event reset and wait |
| 07 | Test happened status |
| 06 | Event reset |
| 05 | Event wait |
| 04 | Event cause |
| 02 | Conditional lock |
| 01 | Unconditional lock |
| 00 | Unlock |

All other BF values cause an invalid instruction fault (IEX = 26).

**A** is the address of the lock/event structure. Address can be indexed, indirect, or extended. The final address controller must be UN, or an invalid instruction fault (IEX = 03) occurs. The final address must be Mod-2, but the hardware does not check it.\\
If BF has a value of 00-02, A represents a lock structure.\\
If BF has a value of 04-10, A represents an event structure.

The lock structure format is as follows:

^ Information ^ Digits ^
| Lock status field | 00-01 |
| Lock owner field | 02-05 |
| Lock waiter link field | 06-09 |
| Lock number field | 10-13 |
| Lock number link field | 14-17 |
| Reserved | 18-19 |

^ Note: The lowest memory address is 00.^

The event structure format is as follows:

^ Information ^ Digits ^
| Event status field | 00-01 |
| Event owner field | 02-05 |
| Event waiter link field | 06-09 |
| Event designator field | 10-13 |
| Event count | 14-19 |

^ Note: The lowest memory address is 00. ^

If any of the lock/event structure values contain undigits, an invalid
instruction (IEX=07) occurs.

^ Note: This instruction only executes with the privileged enable set otherwise an invalid instruction fault (IEX=02) is reported. ^

==== Function ====

LOK examines the lock/event structure (A) and, depending on its value
and the instruction variant (BF), modifies the lock/event structure
(A) and associated lock fields in the [[processor_state:reinstate_list|reinstate list]] entry for the
current task, and other tasks owning or contending for the lock or
event.

The lock waiter link field and the event waiter link field provide the
MCP kernel with the task number, which execution is linked to, for a
specific change of the current lock or event structure.

The lock number field and the lock number link field implement a
canonical lock algorithm to prevent deadlock situations. All locks are
assigned a level number; a task that owns a lock at level
n can only get a lock at level n+1 or greater. A
lock at a level lower than n can be acquired only by a task that
has released all locks at or above that level in reverse order from which
it had acquired them.

The processor must determine if a lock is owned or available. If the
owner field of the lock structure is zero, the lock is available. If the
owner field is not zero, the lock is owned.

The processor must determine if an event has happened. If the event owner
field is zero, the event has happened. If the event state field is not
equal to zero, the event has not happened.

The event designator field ensures that the current structure is an event
structure. A nonzero value in this field causes a fault.

^ Note: The equivalent field in a lock structure (lock number) is always a nonzero value. ^

The event count field identifies a particular occurrence of a particular
event since the same structure can be used for multiple purposes over a
period of time.

The machine-dependent lock status field of the lock/even structure (A)
can also represent the status of the structure, with one value
representing owned, and another representing available. The lock status
field of the lock structure is not used to determine if the lock is
available.

==== Variants ====

The variants are described as follows:

=== BF=00 Unlock ===

This variant releases a Lock and, if any task is waiting for this lock, causes
an interrupt to the MCP kernel.

Obtain exclusive rights to the lock structure specified by the A address.

The value of the lock owner field must equal the current task
number; otherwise, relinquish exclusive access rights
to the lock structure, cause an invalid instruction fault (IEX=06)
and terminate the instruction with no futher action.

Compare the lock number field of the lock structure (A)
with the MCP canonical lock number field located in the
[[processor_state:reinstate_list|reinstate list entry]] for the current task. If they are not
equal, relinquish exclusive access rights to the lock
structure; cause an invalid instruction fault (IEX=06) and
terminate the instruction with no further action.

Otherwise, store zeros into the lock owner field of the
lock structure (A) to indicate that this lock is available.
It also stores the contents of the lock number link field of
the lock structure (A) into the MCP canonical lock number
field that is located in the reinstate list entry for the
current task.

Examine the lock waiter link field of the lock structure. If it is equal to
zero, set the [[processor_state:comparison_flags|Comparison flags]] to **EQUAL**, relinquish exclusive access rights to
the lock structure and terminate the instruction with no further action.

If the lock waiter link field is not equal to zero, perform the following
operations:
- Set the comparison flags to HIGH.
- Assemble and save, within the processor, the released contended lock value for future update of the instruction interrupt cause descriptor in the [[processor_state:kernel_data_area|kernel data area]].
- Assemble and save, within the processor, the pointer to the reinstate list entry of the task specified by the task number in the lock waiter link field of the lock structure (A). The pointer is to be used for update to the instruction interrupt cause extension descriptor (C7AAAAAA).
- Assemble and save, within the processor, the next instruction address. The next instruction address will be used to update the interrupt frame in the reinstate list entry for the current task.
- Relinquish exclusive access rights to the lock structure.
- Perform an interrupt procedure that reports an instruction interrupt in the interrupt descriptor in the [[processor_state:kernel_data_area|kernel data area]].

=== BF=01 Unconditional Lock ===

This variant competes for the lock specified by the Lock Structure (A) and, if
the lock is owned, causes an interrupt to the MCP kernel.

Obtain exclusive rights to the lock structure specified by the A address.

Compare the lock number field of the lock structure (A) with the MCP canonical lock number field located in the reinstate list entry for the current task. If the lock number field is less than or equal to the MCP canonical lock number field, relinquish exclusive access rights to the lock structure, raise an invalid instruction fault (IEX=06) and terminate the instruction.

If the lock is available, perform the following operations:
- Store the active task number in the lock owner field.
- Copy the contents of the MCP canonical lock number field, that is located in the active reinstate list entry, into the lock number link field of the lock structure.
- Copy the contents of the lock number field of the lock structure into the MCP canonical lock number field that is located in the active reinstate list entry.
- Set the comparison flags to **EQUAL**.
- Relinquish exclusive access rights to the lock structure and terminate the instruction.

If the lock is owned, perfrom the following operations:
- Copy the lock owner field of the lock structure (A) into the task number owning field located in the reinstate list entry for the current task.
- Copy the lock waiter link field of the lock structure (A) to the next task in list field located in the reinstate list entry for the current task.
- Store the current task number into the lock waiter link field of the lock structure (A).
- Store the waiting lock value into the state indicator field located in the reinstate list entry for the current task.
- Set the comparison flags to LOW.
- Assemble and save, within the processor, the failed lock value for update of the instruction interrupt cause descriptor in the kernel data area.
- Assemble and save, within the processor the pointer to the reinstate list entry of the task specified by the task number in the lock owner field of the lock structure (A). The pointer is to be used for update to the instruction interrupt cause extension descriptor (C7AAAAAA).
- Assemble and save, within the processor, the next instruction address to point to the instruction following the current instruction for future update of the interrupt frame in the reinstate list entry for the current task.
- Relinquish exclusive access rights to the lock structure.
- Perform an interrupt procedure that reports an instruction interrupt in the interrupt descriptor in the kernel data area.

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.

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? :)

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.

Perhaps

... the mutex shall have been acquired as if by
pthread_mutex_lock and shall be owned...

would be slightly more clear, but the current statement is clear to
those skilled in the art, which is generally the point of a standard.

Muttley@dastardlyhq.com writes:
>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? :)

We were using MCP long before the movie. We (the MCP department) took
a morning off to go to see Tron at a nearby (walking distance) theater
when it came out (the theater was also rented for periodic all-hands
meetings). This was in Pasadena California.

I doubt the scriptwriters had even heard of Burroughs MCP; likely
a parallel development.

On Thu, 09 Feb 2023 14:46:51 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>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.

That also describe the behaviour with signal.

>Is clear and states exactly what you said "clear would be" above.

Its as clear as mud. If people like you write man pages it explains a lot.

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.

As Scott Lurndal already mentioned, this a caveat regarding the
implementation of condition variables: The mutex currently associated
with one must be recorded somewhere. The obvious idea would be whatever
data structure is associated with the condition variable. But that's not
sufficent: If a pthread_cond_broadcast call wakes up all threads waiting
on a condition variable, some of them might not get an actual chance to
run before a subsequent pthread_cond_wait call causes a different mutex
to be associated with it. Hence, the mutex at time of the wakeup must be
recorded somewhere where it remains available to the woken-up threads
regardles of the current state of the condition variable.

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.