Am 02.11.2023 um 16:37 schrieb Kaz Kylheku:

> Firstly, it doesn't have to be binary to be used as a mutex.

No, but when being used as a mutex its actual maximum value is one.

> A semaphore isn't a mutex because it doesn't incorporate the concept
> of lock ownership.

Thats not dependent on actual implementation but how you consider
the value of the binary semaphore. If it is false it is owned.

On 2023-11-02, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 02.11.2023 um 16:37 schrieb Kaz Kylheku:
>
>> Firstly, it doesn't have to be binary to be used as a mutex.
>
> No, but when being used as a mutex its actual maximum value is one.
>
>> A semaphore isn't a mutex because it doesn't incorporate the concept
>> of lock ownership.
>
> Thats not dependent on actual implementation but how you consider
> the value of the binary semaphore. If it is false it is owned.

If it is false, it can be understood as representing a locked state.

Locked isn't necessarily owned.

The semaphore does not record the ID of an owner.

In a correct program, a binary semaphore can represent a lock, yet there
can be legitimate situations where a thread which didn't place the lock
releases it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-11-02, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 02.11.2023 um 15:58 schrieb Scott Lurndal:
>
>> No. Each is distinct.
>
> You can initialize a binary semaphore with true and use it
> as a mutex. And a mutex can be realized without a short path
> but just with a binary semaphore in the mentioned way.

You can use a label, if and goto as a while loop.

That doesn't mean if and goto /are/ while.

Speaking of which, I have often mused that sempahores are like the go to
statement of synchronization---which is ironic, given their inventor.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:

> Locked isn't necessarily owned.
> The semaphore does not record the ID of an owner.

A non-recursive mutes also doesn't do this. The surrounding
code itself is designed in a way that it behaves like an owner.

On 11/2/2023 8:34 AM, David Brown wrote:
> On 02/11/2023 15:58, Scott Lurndal wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 01.11.2023 um 20:58 schrieb Chris M. Thomasson:
>>>
>>>> The benaphore is a semaphore not a mutex! Fwiw, you can use any
>>>> semaphore as a binary semaphore for use as a mutex. Got it?
>>>
>>> A binary semaphore is also a mutex.
>>
>> No.  Each is distinct.
>>
>> It is correct, however, to say that both provide the same functionality.
>>
>
> Both provide /similar/ functionality, but not necessarily the same.
> Different OS's differ in the details, but it is common for mutexes to
> have priority boosting if a high priority thread is waiting for a mutex
> currently held by a low priority thread.  Such boosting is normally not
> part of the functionality of a binary semaphore.  This makes them very
> distinctly different on such OS's - a mutex is a lock, a semaphore
> (binary or otherwise) is a signalling mechanism.

Right. Basically, any thread/process can increment and/or decrement a
semaphore. This is different than pure mutex logic. Even if the mutex
uses a semaphore under the covers...

>
> (I don't know if Windows makes such a distinction - it's not an OS you
> use when thread or process priority is important.  It is certainly
> common, though not universal, for RTOS's.  And while I don't know the
> details, I'd be surprised if Linux and other *nix's didn't have such a
> distinction.)
>

On 11/2/2023 9:00 AM, Kaz Kylheku wrote:
> On 2023-11-02, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 02.11.2023 um 16:37 schrieb Kaz Kylheku:
>>
>>> Firstly, it doesn't have to be binary to be used as a mutex.
>>
>> No, but when being used as a mutex its actual maximum value is one.
>>
>>> A semaphore isn't a mutex because it doesn't incorporate the concept
>>> of lock ownership.
>>
>> Thats not dependent on actual implementation but how you consider
>> the value of the binary semaphore. If it is false it is owned.
>
> If it is false, it can be understood as representing a locked state.
>
> Locked isn't necessarily owned.
>
> The semaphore does not record the ID of an owner.
>
> In a correct program, a binary semaphore can represent a lock, yet there
> can be legitimate situations where a thread which didn't place the lock
> releases it.
>

True. This makes me think of robust mutexes... ;^)

On 02/11/2023 21:12, Chris M. Thomasson wrote:
> On 11/2/2023 8:34 AM, David Brown wrote:
>> On 02/11/2023 15:58, Scott Lurndal wrote:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 01.11.2023 um 20:58 schrieb Chris M. Thomasson:
>>>>
>>>>> The benaphore is a semaphore not a mutex! Fwiw, you can use any
>>>>> semaphore as a binary semaphore for use as a mutex. Got it?
>>>>
>>>> A binary semaphore is also a mutex.
>>>
>>> No.  Each is distinct.
>>>
>>> It is correct, however, to say that both provide the same functionality.
>>>
>>
>> Both provide /similar/ functionality, but not necessarily the same.
>> Different OS's differ in the details, but it is common for mutexes to
>> have priority boosting if a high priority thread is waiting for a
>> mutex currently held by a low priority thread.  Such boosting is
>> normally not part of the functionality of a binary semaphore.  This
>> makes them very distinctly different on such OS's - a mutex is a lock,
>> a semaphore (binary or otherwise) is a signalling mechanism.
>
> Right. Basically, any thread/process can increment and/or decrement a
> semaphore. This is different than pure mutex logic. Even if the mutex
> uses a semaphore under the covers...
>

That's a very different issue - though of course it is an equally
important distinction between mutexes and binary semaphores. (And no, a
mutex cannot be implemented using semaphores if the mutex has protection
against priority inversion, and the semaphore does not.)

>>
>> (I don't know if Windows makes such a distinction - it's not an OS you
>> use when thread or process priority is important.  It is certainly
>> common, though not universal, for RTOS's.  And while I don't know the
>> details, I'd be surprised if Linux and other *nix's didn't have such a
>> distinction.)
>>
>

On 02/11/2023 17:26, Bonita Montero wrote:
> Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:
>
>> Locked isn't necessarily owned.
>> The semaphore does not record the ID of an owner.
>
> A non-recursive mutes also doesn't do this. The surrounding
> code itself is designed in a way that it behaves like an owner.

Mutexes - recursive or non-recursive - /do/ record their owner when the
lock is taken. Only the owner can unlock the mutex again. This is
completely different from semaphores, where by design any thread can
raise or lower the semaphore.

Am 03.11.2023 um 10:15 schrieb David Brown:
> On 02/11/2023 17:26, Bonita Montero wrote:
>> Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:
>>
>>> Locked isn't necessarily owned.
>>> The semaphore does not record the ID of an owner.
>>
>> A non-recursive mutes also doesn't do this. The surrounding
>> code itself is designed in a way that it behaves like an owner.
>
> Mutexes - recursive or non-recursive - /do/ record their owner when the
> lock is taken. ...

Absolutely not. You can take ownership of a mutex in one thread and
release it in another thread. The mentioned benaphore, which is the
basic skeleton for all mutexes, is a good example for that.

Am 01.11.2023 um 21:02 schrieb Chris M. Thomasson:

> If you can avoid using a CAS, aka CMPXCHG over on intel, then do it!
> Although, wrt intel, there is a way to use CMPXCHG without looping.

I don't believe that, give me some code-example _here_. The expected
value of a compare exchange might always have been asynchronously
changed, so you need looping every time.

> Think, strong CAS vs weak CAS...

Strong CAS vs. weak CAS only makes a difference of architectures with
LL/SC. With these architectures a CAS may fail although the actual
data corresponds with the expected value because the cacheline might
have been evicted in the meantime. compare_exchange_strong checks for
this case and loops internally, whereas compare_exchange_weak gives a
false result after one try.

On 03/11/2023 11:55, Bonita Montero wrote:
> Am 03.11.2023 um 10:15 schrieb David Brown:
>> On 02/11/2023 17:26, Bonita Montero wrote:
>>> Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:
>>>
>>>> Locked isn't necessarily owned.
>>>> The semaphore does not record the ID of an owner.
>>>
>>> A non-recursive mutes also doesn't do this. The surrounding
>>> code itself is designed in a way that it behaves like an owner.
>>
>> Mutexes - recursive or non-recursive - /do/ record their owner when
>> the lock is taken. ...
>
> Absolutely not. You can take ownership of a mutex in one thread and
> release it in another thread. The mentioned benaphore, which is the
> basic skeleton for all mutexes, is a good example for that.
>

You can call that a mutex if you like, but you'd be wrong. You could
call it a banana, and you would do no worse.

Wikipedia may not be have any particular authority on its definitions,
but it explains the difference between mutexes and semaphores quite well:

<https://en.wikipedia.org/wiki/Lock_(computer_science)#Mutexes_vs._semaphores>

Critical to the point of a mutex is that only the thread that locks it
can unlock it.

You can look at the notes for C++ semaphores here, which make the
distinction clear:

<https://en.cppreference.com/w/cpp/thread/counting_semaphore>

Documentation for C++ mutexes is here :

<https://en.cppreference.com/w/cpp/thread/mutex>
<https://en.cppreference.com/w/cpp/thread/mutex/unlock>

Or you can read the C++ standards if you prefer. (I find the
cppreference pages much easier to follow.)

Or you can look up the documentation for Windows mutexes on MS's webpages.

On Wed, 1 Nov 2023 19:24:06 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:

> Am 01.11.2023 um 13:00 schrieb Bonita Montero:
>
> > I guess he wouldn't have given the benaphore its name because its
> > the simplest form of a mutex and you can find for sure a lot of
> > similar implementations of that on the net.
>
> I found that the name benaphore was given 1996. Maybe this was the
> first time this idea was published. But this idea is that obvious
> that I had it myself that I think there were several people which
> also had this idea before 1996. A hint on how soon this has been
> invented may be the introduction of the LOCK XADD instruction which
> makes this kind of mutex implementable more efficient than with
> LOCK CMPXCHG because this operation never fails.
>

Semophores can be efficiently implemented on "old" x86 by means of
'LOCK ADD mem, reg'. It is possible due to arithmetic flags generated
by ADD instructiion. As far as semaphores goes 'LOCK XADD' adds little
or nothing to efficiency over 'LOCK ADD'. XADD is just easier to use as
an intrinsic from C or similar languages.

On Thu, 2 Nov 2023 16:02:04 -0000 (UTC)
Kaz Kylheku <864-117-4973@kylheku.com> wrote:

> On 2023-11-02, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> > Am 02.11.2023 um 15:58 schrieb Scott Lurndal:
> >
> >> No. Each is distinct.
> >
> > You can initialize a binary semaphore with true and use it
> > as a mutex. And a mutex can be realized without a short path
> > but just with a binary semaphore in the mentioned way.
>
> You can use a label, if and goto as a while loop.
>
> That doesn't mean if and goto /are/ while.
>
> Speaking of which, I have often mused that sempahores are like the go
> to statement of synchronization---which is ironic, given their
> inventor.
>

IMHO, the word 'mutex' has no exact meaning agreed by all or even
majority of Computer Science community.

Am 03.11.2023 um 14:41 schrieb David Brown:
> On 03/11/2023 11:55, Bonita Montero wrote:
>> Am 03.11.2023 um 10:15 schrieb David Brown:
>>> On 02/11/2023 17:26, Bonita Montero wrote:
>>>> Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:
>>>>
>>>>> Locked isn't necessarily owned.
>>>>> The semaphore does not record the ID of an owner.
>>>>
>>>> A non-recursive mutes also doesn't do this. The surrounding
>>>> code itself is designed in a way that it behaves like an owner.
>>>
>>> Mutexes - recursive or non-recursive - /do/ record their owner when
>>> the lock is taken. ...
>>
>> Absolutely not. You can take ownership of a mutex in one thread and
>> release it in another thread. The mentioned benaphore, which is the
>> basic skeleton for all mutexes, is a good example for that.
>>
>
> You can call that a mutex if you like, but you'd be wrong.  You could
> call it a banana, and you would do no worse.
> Wikipedia may not be have any particular authority on its definitions,
> but it explains the difference between mutexes and semaphores quite well:
> <https://en.wikipedia.org/wiki/Lock_(computer_science)#Mutexes_vs._semaphores>
> Critical to the point of a mutex is that only the thread that locks it
> can unlock it.
> You can look at the notes for C++ semaphores here, which make the
> distinction clear:

At this point in the thread I was discussion whether a mutex has the
notion of an ownership and it mutexes vs. semaphores.

>
> <https://en.cppreference.com/w/cpp/thread/counting_semaphore>
>
> Documentation for C++ mutexes is here :
>
> <https://en.cppreference.com/w/cpp/thread/mutex>
> <https://en.cppreference.com/w/cpp/thread/mutex/unlock>
>
> Or you can read the C++ standards if you prefer.  (I find the
> cppreference pages much easier to follow.)
>
> Or you can look up the documentation for Windows mutexes on MS's webpages.
>

Am 03.11.2023 um 15:04 schrieb Michael S:

> Semophores can be efficiently implemented on "old" x86 by means of
> 'LOCK ADD mem, reg'. ...

Semaphores need much more code and this code is usually in the kernel
since with a semaphore a thread may go to sleep or be awakened.

On 2023-11-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 03.11.2023 um 10:15 schrieb David Brown:
>> On 02/11/2023 17:26, Bonita Montero wrote:
>>> Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:
>>>
>>>> Locked isn't necessarily owned.
>>>> The semaphore does not record the ID of an owner.
>>>
>>> A non-recursive mutes also doesn't do this. The surrounding
>>> code itself is designed in a way that it behaves like an owner.
>>
>> Mutexes - recursive or non-recursive - /do/ record their owner when the
>> lock is taken. ...
>
> Absolutely not. You can take ownership of a mutex in one thread and
> release it in another thread.

Not POSIX mutexes: pthread_mutex_unlock by a non-owner is either
undefined behavior, or a condition diagnosed by an error return value,
depending on the mutex attributes:

See the table here:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html

E.g. for a norma mutex type which is not attributed as robust,
it is undefined behavior.

Support for unlocking by a non-owner is possible in a mutex, but that's
a non-mutex-like behavioral extension.

A mutex that is owned by a process, rather than a thread, can be locked
by one thread and unlocked by another. Classic POSIX file locks (F_SETLK
code of fcntl, etc) are like this, IIRC. That's still mutex-like, just
the scope is process, rather than thread.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 03/11/2023 15:22, Bonita Montero wrote:
> Am 03.11.2023 um 14:41 schrieb David Brown:
>> On 03/11/2023 11:55, Bonita Montero wrote:
>>> Am 03.11.2023 um 10:15 schrieb David Brown:
>>>> On 02/11/2023 17:26, Bonita Montero wrote:
>>>>> Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:
>>>>>
>>>>>> Locked isn't necessarily owned.
>>>>>> The semaphore does not record the ID of an owner.
>>>>>
>>>>> A non-recursive mutes also doesn't do this. The surrounding
>>>>> code itself is designed in a way that it behaves like an owner.
>>>>
>>>> Mutexes - recursive or non-recursive - /do/ record their owner when
>>>> the lock is taken. ...
>>>
>>> Absolutely not. You can take ownership of a mutex in one thread and
>>> release it in another thread. The mentioned benaphore, which is the
>>> basic skeleton for all mutexes, is a good example for that.
>>>
>>
>> You can call that a mutex if you like, but you'd be wrong.  You could
>> call it a banana, and you would do no worse.
>> Wikipedia may not be have any particular authority on its definitions,
>> but it explains the difference between mutexes and semaphores quite well:
>> <https://en.wikipedia.org/wiki/Lock_(computer_science)#Mutexes_vs._semaphores>
>> Critical to the point of a mutex is that only the thread that locks it
>> can unlock it.
>> You can look at the notes for C++ semaphores here, which make the
>> distinction clear:
>
> At this point in the thread I was discussion whether a mutex has the
> notion of an ownership and it mutexes vs. semaphores.
>

And using the definitions held by most people involved (including the
C++ standard library, the Windows API, and AFAIK POSIX), mutexes have
ownership and semaphores do not. A semaphore is not a lock, it is a
signalling mechanism - and any thread can signal it up or down. A mutex
is a locking mechanism to ensure mutually exclusive access to some
resource, and only the owner can release the lock (baring exceptional
circumstances, such as a process being killed by the OS). A sort-of
mutex where any thread could release the lock would be as useful as a
chocolate teapot - as would a semaphore which could only be lowered by
the thread that raised it.

>>
>> <https://en.cppreference.com/w/cpp/thread/counting_semaphore>
>>
>> Documentation for C++ mutexes is here :
>>
>> <https://en.cppreference.com/w/cpp/thread/mutex>
>> <https://en.cppreference.com/w/cpp/thread/mutex/unlock>
>>
>> Or you can read the C++ standards if you prefer.  (I find the
>> cppreference pages much easier to follow.)
>>
>> Or you can look up the documentation for Windows mutexes on MS's
>> webpages.
>>
>

Am 03.11.2023 um 16:35 schrieb David Brown:

> And using the definitions held by most people involved (including the
> C++ standard library, the Windows API, and AFAIK POSIX), mutexes have
> ownership and semaphores do not. ...

Mutexes only have ownership if they're recursive. Otherwise you
can easily unlock a mutex which was locked in another thread.

> A semaphore is not a lock, ...

It can be used as a lock although it is not recommended because
a semaphore is usually a pure kernel facility.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 03.11.2023 um 10:15 schrieb David Brown:
>> On 02/11/2023 17:26, Bonita Montero wrote:
>>> Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:
>>>
>>>> Locked isn't necessarily owned.
>>>> The semaphore does not record the ID of an owner.
>>>
>>> A non-recursive mutes also doesn't do this. The surrounding
>>> code itself is designed in a way that it behaves like an owner.
>>
>> Mutexes - recursive or non-recursive - /do/ record their owner when the
>> lock is taken. ...
>
>Absolutely not. You can take ownership of a mutex in one thread and
>release it in another thread.

That has to be the worst idea you've proposed so far.

On 03/11/2023 16:49, Bonita Montero wrote:
> Am 03.11.2023 um 16:35 schrieb David Brown:
>
>> And using the definitions held by most people involved (including the
>> C++ standard library, the Windows API, and AFAIK POSIX), mutexes have
>> ownership and semaphores do not. ...
>
> Mutexes only have ownership if they're recursive. Otherwise you
> can easily unlock a mutex which was locked in another thread.
>

Please read <https://en.cppreference.com/w/cpp/thread/mutex/unlock>.
Note the sentence "The mutex must be locked by the current thread of
execution, otherwise, the behavior is undefined."

Please read the C++ standards, section [thread.mutex.requirements.mutex]
and note that for "unlock()", there is the sentence "Preconditions: The
calling thread owns the mutex."

Please learn what "undefined behaviour" means, and what "preconditions"
mean.

Then come back and apologise.

>> A semaphore is not a lock, ...
>
> It can be used as a lock although it is not recommended because
> a semaphore is usually a pure kernel facility.
>

Using a semaphore as a lock is not recommended because a semaphore does
not make a good lock. A main reason for that is that it has no concept
of ownership. /All/ locking and inter-thread signalling mechanisms rely
on kernel facilities, because they need to be able to sleep, and to wake
sleeping threads.

On 03/11/2023 16:32, Kaz Kylheku wrote:
> On 2023-11-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 03.11.2023 um 10:15 schrieb David Brown:
>>> On 02/11/2023 17:26, Bonita Montero wrote:
>>>> Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:
>>>>
>>>>> Locked isn't necessarily owned.
>>>>> The semaphore does not record the ID of an owner.
>>>>
>>>> A non-recursive mutes also doesn't do this. The surrounding
>>>> code itself is designed in a way that it behaves like an owner.
>>>
>>> Mutexes - recursive or non-recursive - /do/ record their owner when the
>>> lock is taken. ...
>>
>> Absolutely not. You can take ownership of a mutex in one thread and
>> release it in another thread.
>
> Not POSIX mutexes: pthread_mutex_unlock by a non-owner is either
> undefined behavior, or a condition diagnosed by an error return value,
> depending on the mutex attributes:
>
> See the table here:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html
>
> E.g. for a norma mutex type which is not attributed as robust,
> it is undefined behavior.
>
> Support for unlocking by a non-owner is possible in a mutex, but that's
> a non-mutex-like behavioral extension.
>
> A mutex that is owned by a process, rather than a thread, can be locked
> by one thread and unlocked by another. Classic POSIX file locks (F_SETLK
> code of fcntl, etc) are like this, IIRC. That's still mutex-like, just
> the scope is process, rather than thread.
>

Mutexes are locks, but not all locks are mutexes. File locks are not
mutexes - they are for controlling access to files, and it might
(rarely) make sense to unlock them from a different thread than the
locking thread.

Am 03.11.2023 um 18:02 schrieb David Brown:

> Please read <https://en.cppreference.com/w/cpp/thread/mutex/unlock>.
> Note the sentence "The mutex must be locked by the current thread of
> execution, otherwise, the behavior is undefined."

Maybe, but I'm talking about how mutexes usually work internally.

> Using a semaphore as a lock is not recommended because a semaphore does
> not make a good lock.  A main reason for that is that it has no concept
> of ownership. ...

Mutexes also usually have no notion of ownership.

Am 03.11.2023 um 17:53 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 03.11.2023 um 10:15 schrieb David Brown:
>>> On 02/11/2023 17:26, Bonita Montero wrote:
>>>> Am 02.11.2023 um 17:00 schrieb Kaz Kylheku:
>>>>
>>>>> Locked isn't necessarily owned.
>>>>> The semaphore does not record the ID of an owner.
>>>>
>>>> A non-recursive mutes also doesn't do this. The surrounding
>>>> code itself is designed in a way that it behaves like an owner.
>>>
>>> Mutexes - recursive or non-recursive - /do/ record their owner when the
>>> lock is taken. ...
>>
>> Absolutely not. You can take ownership of a mutex in one thread and
>> release it in another thread.
>
> That has to be the worst idea you've proposed so far.

I won't say that this is recommendable but just that it is possible
from the way how a mutex usually works. I just wanted to say with
that that mutexes usually have no ownership. You can see that with
the benapohre.

On 2023-11-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 03.11.2023 um 16:35 schrieb David Brown:
>
>> And using the definitions held by most people involved (including the
>> C++ standard library, the Windows API, and AFAIK POSIX), mutexes have
>> ownership and semaphores do not. ...
>
> Mutexes only have ownership if they're recursive. Otherwise you
> can easily unlock a mutex which was locked in another thread.

That depends entirely on which kind of mutex on what platform.

- POSIX mutexes make that either an error, or undefined behavior,
depending on the mutex attributes.

- MSDN says this about critical sections: "If a thread calls
LeaveCriticalSection when it does not have ownership of the specified
critical section object, an error occurs that may cause another thread
using EnterCriticalSection to wait indefinitely."

- MSDN, again, about Win32 mutex objects: "The ReleaseMutex function
fails if the calling thread does not own the mutex object."

- ISO C (since C11) mtx_unlock: undefined behavior if mutex is not
locked by the calling thread.

- C++ std::mutex::unlock: ditto.

At this point, I'm already well into stuff I don't give a shit about,
to look for more. I don't care if ScrotelyOS developed in Ruritania
between 1973 and 1981 had "mutexes" that had up to three owners.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-11-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 03.11.2023 um 18:02 schrieb David Brown:
>
>> Please read <https://en.cppreference.com/w/cpp/thread/mutex/unlock>.
>> Note the sentence "The mutex must be locked by the current thread of
>> execution, otherwise, the behavior is undefined."
>
> Maybe, but I'm talking about how mutexes usually work internally.

"Never mind that a[i++] = i is undefined; I'm talking about how it
works internally, damn it!!!"

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.