Am 03.11.2023 um 18:28 schrieb Kaz Kylheku:

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

The discussed benaphore allows this.

On 2023-11-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 03.11.2023 um 18:28 schrieb Kaz Kylheku:
>
>> 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.
>
> The discussed benaphore allows this.

That's a kind of semaphore, and its name reflects that.

Benoit Schillings introduced this word as an optimization that is
for certain inefficient semaphore implementations:

https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26

He recommends this:

void acquire_benaphore()
{
long previous_value;
previous_value = atomic_add (&benaphore_atom, 1);

if (previous_value > 0)
acquire_sem(benaphore_sem);
}

Firstly, this is not a mutex but a semaphore. Secondly, it only makes
sense if acquire_sem is somehow expensive (like a trap to the kernel).

The reason is that acquire_sem already looks like acquire_benaphore:

void acquire_sem(semaphore *s)
{
long prev = atomic_add(&s->counter);

if (prev > 0) {
// suspend caller somehow
}

// ...

}

--
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 03.11.2023 um 19:03 schrieb Kaz Kylheku:
> On 2023-11-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:

>> Am 03.11.2023 um 18:28 schrieb Kaz Kylheku:

>> The discussed benaphore allows this.

> That's a kind of semaphore, and its name reflects that.

It's a mutex, look at the code.
And look at the discussion on stack overflow about that:
https://stackoverflow.com/questions/1635416/are-benaphores-worth-implementing-on-modern-oss

Am 03.11.2023 um 19:07 schrieb Bonita Montero:

> It's a mutex, look at the code.
> And look at the discussion on stack overflow about that:
> https://stackoverflow.com/questions/1635416/are-benaphores-worth-implementing-on-modern-oss

And this article also refers to it as a mutex:
https://preshing.com/20120226/roll-your-own-lightweight-mutex/

David Brown <david.brown@hesbynett.no> writes:
>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."
>

And read the POSIX standard as well.

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

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

Bonita Montero <Bonita.Montero@gmail.com> writes:
>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.

Why does that matter? It's the behavior seen by the code
using the mutex that matters.

Undefined behavior isn't something an application can rely on.

You keep digging yourself deeper and deeper.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 03.11.2023 um 18:28 schrieb Kaz Kylheku:
>
>> 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.
>
>The discussed benaphore allows this.

And which operating system offers this soi disant 'benaphore' as a
synchronization mechanism?

Am 03.11.2023 um 19:54 schrieb Scott Lurndal:

> And which operating system offers this soi disant 'benaphore' as a
> synchronization mechanism?

Non-recursive mutexes mostly base on the same mechanisms since
an atomic add doesn't need looping.

On 2023-11-03, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 03.11.2023 um 19:54 schrieb Scott Lurndal:
>
>> And which operating system offers this soi disant 'benaphore' as a
>> synchronization mechanism?
>
> Non-recursive mutexes mostly base on the same mechanisms since
> an atomic add doesn't need looping.

An atomic counter, featuring a wait when the value is in a certain
range, is known as semaphore.

--
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-10-30, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> MSVC's C++20 semaphore class spins to acquire the semaphore;
> g++'s / libstdc++'s doesn't spin. I wote a little test program
> to rest how long it takes to flip to another thread and back
> with a binary_semaphore (always a counting_semaphore<1>).
> Here it is:
>
> #if defined(_WIN32)
> #include <Windows.h>
> #elif defined(__unix__)
> #include <sys/resource.h>
> #endif
> #include <iostream>
> #include <thread>
> #include <semaphore>
> #include <atomic>
> #include <utility>
> #include <vector>
>
> using namespace std;
>
> int main()
> {
> binary_semaphore
> semA( 1 ),
> semB( 0 );
> auto getTimes = []() -> pair<int64_t, int64_t>
> {
> #if defined(_WIN32)
> FILETIME ftDummy, ftKernel, ftUser;
> GetThreadTimes( GetCurrentThread(), &ftDummy, &ftDummy, &ftKernel,
> &ftUser );
> auto compose = []( FILETIME &ft ) { return
> ((uint64_t)ft.dwHighDateTime << 32 | ft.dwLowDateTime) * 100; };
> return { compose( ftKernel ), compose( ftUser ) };
> #elif defined(__unix__)
> rusage ru;
> getrusage( RUSAGE_THREAD, &ru );
> auto compose = []( timeval &tv ) -> int64_t { return
> (uint64_t)tv.tv_sec * 1'000'000'000u + (uint32_t)tv.tv_usec * 1'000u; };
> return { compose( ru.ru_stime ), compose( ru.ru_utime ) };
> #endif
> };
> atomic_int64_t
> aFlips( 0 ),
> aKernel( 0 ),
> aUser( 0 );
> atomic_bool stop( false );
> auto thr = [&]( binary_semaphore &semMe, binary_semaphore &semYou )
> {
> auto tBegin = getTimes();
> uint64_t f = 0;
> for( ; !stop.load( memory_order_relaxed ); ++f )
> semMe.acquire(),
> semYou.release();
> auto tEnd = getTimes();
> aFlips += f;
> aKernel += tEnd.first - tBegin.first;
> aUser += tEnd.second + tBegin.second;
> };
> vector<jthread> threads;
> threads.emplace_back( thr, ref( semA ), ref( semB ) );
> threads.emplace_back( thr, ref( semB ), ref( semA ) );
> this_thread::sleep_for( 1s );
> stop = true;
> threads.resize( 0 );
> double
> kernel = (double)aKernel,
> user = (double)aUser,
> total = kernel + user,
> flips = (double)aFlips;
> cout << user / total * 100.0 << "%" << endl;
> cout << total / flips << "ns" << endl;
> }
>
> Results unter Windows 11 on a AMD Ryzen 7950X (Zen4):
> 100%
> 89.3523ns
> So 100% of the CPU time is spent in user space and a flip back
> and forth takes 90ns.
> Results unter Ubuntu 20.04 on a AMD Threadripper 3990X (Zen2):
> 6.56209%
> 476.213ns
> So under Linux most of the time is spent in kernel space and I think
> about 0.5us, thats about 2000 clock cycles with full boost, isn't bad
> for an explicit kernel call.
> I think this userland spinning isn't really necessary because you
> normally a usual mutex and a condition_variable fits for everything
> you need. An explicit semaphore is rather needed if you build your
> own synchronization primitves on top of the semaphore. And if you do
> that you usually have your own spinning with that and you don't need
> further spinning if you want go into kernel mode. But this additional
> spinning actually doesn't really hurt since the kernel call itself
> costs a lot more.
>
maxa@Branimirs-MacBook-Air News % g++ -O2 run.cpp -o run -std=c++20
run.cpp:37:2: warning: non-void lambda does not return a value [-Wreturn-type]
};
^
1 warning generated.
bmaxa@Branimirs-MacBook-Air News % ./run
libc++abi: terminating
zsh: abort ./run

--

7-77-777, Evil Sinner!
https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/

On 11/3/2023 5:36 AM, Bonita Montero wrote:
> 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.

Strong CAS cannot fail spuriously. Put on your thinking cap.

On 11/3/2023 7:24 AM, Bonita Montero wrote:
> 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.

Huh? A semaphore in userspace is doable. We use a kernel semaphore for
the slow paths.

On 11/3/2023 2:13 AM, David Brown wrote:
> 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.)

Agreed. Basically, the benaphore is a bakery algorithm. It has FIFO on
the mind... So, you are right.

>
>>>
>>> (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/3/2023 3:55 AM, 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.

Oh, really!?!?!? Yikes!

> The mentioned benaphore, which is the
> basic skeleton for all mutexes, is a good example for that.

Oh my. A benaphore is basically a userspace semaphore using a kernel
semaphore for slow paths.

On 11/3/2023 8:49 AM, 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.

WHAT!!! ? ;^o

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

On 11/3/2023 10:02 AM, David Brown wrote:
> 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.

If I wait for that day, well, I will most likely be dead.

>
>>> 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 11/3/2023 10:08 AM, Bonita Montero 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.
>
>
>> 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.
>

The Art of Trolling, 123, all is me...

On 11/3/2023 9:53 AM, Scott Lurndal wrote:
> 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.

That should be framed! ;^O

On 11/3/2023 10:09 AM, Bonita Montero wrote:
> 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.
>

Oh shit. You have dug yourself into a really deep hole here, Bonita.

wow.

On 11/3/2023 11:08 AM, Bonita Montero wrote:
> Am 03.11.2023 um 19:07 schrieb Bonita Montero:
>
>> It's a mutex, look at the code.
>> And look at the discussion on stack overflow about that:
>> https://stackoverflow.com/questions/1635416/are-benaphores-worth-implementing-on-modern-oss
>
> And this article also refers to it as a mutex:
> https://preshing.com/20120226/roll-your-own-lightweight-mutex/
>

Oh my god...

On 11/1/2023 12:59 PM, Chris M. Thomasson wrote:
> On 11/1/2023 5:21 AM, Bonita Montero wrote:
>> Am 31.10.2023 um 21:59 schrieb Chris M. Thomasson:
>>
>>> Why do you say that?
>>
>> The article you mentioned is also discussed here:
>> https://stackoverflow.com/questions/1635416/are-benaphores-worth-implementing-on-modern-oss
>> The first replier says the same I said: its a normal mutex.
>>
>
> Huh? The benaphore is a semaphore! So, both of you are totally wrong
> here. Think about it...

Your theme song?

https://youtu.be/FE-hBbBBGBs

On 11/3/2023 3:13 PM, Chris M. Thomasson wrote:
> On 11/3/2023 5:36 AM, Bonita Montero wrote:
>> 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.
>
> Strong CAS cannot fail spuriously. Put on your thinking cap.
>

CMPXCHG cannot fail spuriously. However, LL/SC can.

Am 04.11.2023 um 08:19 schrieb Chris M. Thomasson:
> On 11/3/2023 3:13 PM, Chris M. Thomasson wrote:

>> On 11/3/2023 5:36 AM, Bonita Montero wrote:

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

>> Strong CAS cannot fail spuriously. Put on your thinking cap.

> CMPXCHG cannot fail spuriously. However, LL/SC can.

Youre telling things I've told above in a different way.

Am 03.11.2023 um 21:56 schrieb Kaz Kylheku:

> An atomic counter, featuring a wait when the value is in a certain
> range, is known as semaphore.

An atomic counter alone isn't sufficient for a semaphore because
there's no way to sleep or to be awakened with that.

Am 03.11.2023 um 23:19 schrieb Chris M. Thomasson:
> On 11/3/2023 8:49 AM, 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.
>
> WHAT!!! ? ;^o

It't the surrounding code that "knows" that it is
an owner, not the mutex itself. A non-recurive mutex
just knows that it is owned, but not by whom.