Am 03.11.2023 um 23:25 schrieb Chris M. Thomasson:

> On 11/3/2023 10:09 AM, Bonita Montero wrote:

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

The benaphore does know that it is owned, but not by whom.
Its the surrounding code that knows that it owns the mutex.

Am 03.11.2023 um 23:18 schrieb Chris M. Thomasson:

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

There isn't sth. like a userspace semaphore since with a sempahore
you need support to sleep or to be awakened.

Am 01.11.2023 um 20:59 schrieb Chris M. Thomasson:

> Huh? The benaphore is a semaphore! So, both of you are totally wrong
> here. Think about it...

Google for "benaphore mutex" and you'll find several refernces that a
benaphore is a mutex, including the two articles I've referred so far.

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's not necessary to record ownership of a specific thread for a non
recursive mutex but just _that_ a mutex is ownend, and not by whom.
The benaphore can easily locked in one thread and unlocked in another
thread, although this usually doesn't happen.
It's just the surrounding code that successfully locked a mutex that
"knows" it is the owner.

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

Maybe I missed some header which is implicitly included with me.
The code compiles fine with g++, clang++, clang-cl and MSVC on
my PC.

Am 03.11.2023 um 22:18 schrieb Branimir Maksimovic:
> 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
>

Am 04.11.2023 um 10:19 schrieb Bonita Montero:

> Google for "benaphore mutex" ...
Or rather "benaphore mutex -semaphore".

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>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.

LL/SC is not compare and swap.

Am 04.11.2023 um 16:53 schrieb Scott Lurndal:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> 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.
>
> LL/SC is not compare and swap.

Cite where I said sth. opposite.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>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.
>

BTW - Compare and Swap was invented by an engineer at IBM -
CAS is a backronym, the inventors initials are CAS.

https://www.garlic.com/~lynn/2004l.html#56

"charlie had come up with compare and swap at the science scenter
http://www.garlic.com/~lynn/subtopic.html#545tech
based on a lot of work he was doing in fine grain locking (late 60s)
... and tried to get it into 370 architecture. POK architecture owners
came back and said it wasn't possible to justify a multiprocessor-specific
instruction for the 370 architecture (already having test&set) ... and that
to get it justified, it would be necessary to come up with a non-multiprocessor
use for the instruction. thus was born the description for multi-threaded
application use in non-locked regions .... when running on either
multiprocessor or non-multiprocessor machines. this was originally
included in the 370 prinicple of operations as programming notes
associated with the compare&swap instruction(s). the description has
since been expanded and moved to the principles of operation appendix.

note that the choice of compare and swap comes from needing a mnemonic
that matched charlie's initials (CAS). the mnemonic was slightly changed
for inclusion in 370 to CS (compare and swap) and CDS (compare double and swap).

the instructions have since been expanded for 64-bit operation and a
new "perform locked operation" has since been added.

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

Sure there is. It's even obvious.

On 03/11/2023 18:08, 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.
>

I think, from this thread, it is clear that you have no idea how mutexes
are used. I therefore assume you have no idea how they work internally.
And I am entirely confident that your idea of "usually" is limited to
one single OS.

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

I stand corrected. Your idea of "usually" is limited to no OS in existence.

Am 04.11.2023 um 17:22 schrieb David Brown:

> I think, from this thread, it is clear that you have no idea how mutexes
> are used. ...

I use them every day and I've developed my own reader's-writer-lock.

> I stand corrected.  Your idea of "usually" is limited to no OS in
> existence.

A non-recurive mutex doensn't need to know which thread is the
owner, but just that there's an owner.

Am 04.11.2023 um 17:05 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> 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.
>
> Sure there is. It's even obvious.

Not for Kaz.

On 04/11/2023 17:35, Bonita Montero wrote:
> Am 04.11.2023 um 17:22 schrieb David Brown:
>
>> I think, from this thread, it is clear that you have no idea how
>> mutexes are used. ...
>
> I use them every day and I've developed my own reader's-writer-lock.
>

Do you do all your work relying on luck?

>> I stand corrected.  Your idea of "usually" is limited to no OS in
>> existence.
>
> A non-recurive mutex doensn't need to know which thread is the
> owner, but just that there's an owner.
>

No, it needs to know the owner - because only the owner is allowed to
release the lock.

I suppose you could make a half-arsed mutex implementation that relies
on programmers never making mistakes, and just let the nasal demons fly
when people like you can't read and follow specifications.

And even if you have such a poor mutex implementation, conceptually
there is always an owner when the lock is taken - that's the point of
the thing.

Am 04.11.2023 um 17:56 schrieb David Brown:

> No, it needs to know the owner - because only the owner is allowed to
> release the lock.

This is a superfluous check that does not determine function.

> I suppose you could make a half-arsed mutex implementation that relies
> on programmers never making mistakes, and just let the nasal demons fly
> when people like you can't read and follow specifications.

It may be possible to release a mutex from another thread, but as no
one does this this check doesn't make sense. That that much unlikely
that that happens that it doesn't make sense as a debugging aid, even
more in C++, where you can't forget unlocking inside the same thread
if you use a unique_lock<> or lock_guard<>.

On 11/4/2023 8:53 AM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> 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.
>
> LL/SC is not compare and swap.
>
>

LL/SC can be used to implement a weak CAS. Also, wrt the algorithm, it
can be used to implement a strong CAS.

CMPXCHG over on intel cannot be used to implement a weak CAS.

On 2023-11-04, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> 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.

You're not successfully making it appear as if I said that.

--
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 11/4/2023 9:03 AM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> 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.
>>
>
> BTW - Compare and Swap was invented by an engineer at IBM -
> CAS is a backronym, the inventors initials are CAS.
>
> https://www.garlic.com/~lynn/2004l.html#56
>
>
> "charlie had come up with compare and swap at the science scenter
> http://www.garlic.com/~lynn/subtopic.html#545tech
> based on a lot of work he was doing in fine grain locking (late 60s)
> ... and tried to get it into 370 architecture. POK architecture owners
> came back and said it wasn't possible to justify a multiprocessor-specific
> instruction for the 370 architecture (already having test&set) ... and that
> to get it justified, it would be necessary to come up with a non-multiprocessor
> use for the instruction. thus was born the description for multi-threaded
> application use in non-locked regions .... when running on either
> multiprocessor or non-multiprocessor machines. this was originally
> included in the 370 prinicple of operations as programming notes
> associated with the compare&swap instruction(s). the description has
> since been expanded and moved to the principles of operation appendix.
>
> note that the choice of compare and swap comes from needing a mnemonic
> that matched charlie's initials (CAS). the mnemonic was slightly changed
> for inclusion in 370 to CS (compare and swap) and CDS (compare double and swap).
>
> the instructions have since been expanded for 64-bit operation and a
> new "perform locked operation" has since been added.
>
>

Yup. I have actually conversed with Lynn over on comp.arch. Very smart
person loaded up with knowledge.

On 11/4/2023 11:45 AM, Chris M. Thomasson wrote:
> On 11/4/2023 9:03 AM, Scott Lurndal wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>> 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.
>>>
>>
>> BTW - Compare and Swap was invented by an engineer at IBM -
>> CAS is a backronym, the inventors initials are CAS.
>>
>> https://www.garlic.com/~lynn/2004l.html#56
>>
>>
>>    "charlie had come up with compare and swap at the science scenter
>>       http://www.garlic.com/~lynn/subtopic.html#545tech
>>     based on a lot of work he was doing in fine grain locking (late 60s)
>>     ... and tried to get it into 370 architecture. POK architecture
>> owners
>>     came back and said it wasn't possible to justify a
>> multiprocessor-specific
>>     instruction for the 370 architecture (already having test&set) ...
>> and that
>>     to get it justified, it would be necessary to come up with a
>> non-multiprocessor
>>     use for the instruction. thus was born the description for
>> multi-threaded
>>     application use in non-locked regions .... when running on either
>>     multiprocessor or non-multiprocessor machines. this was originally
>>     included in the 370 prinicple of operations as programming notes
>>     associated with the compare&swap instruction(s). the description has
>>     since been expanded and moved to the principles of operation
>> appendix.
>>
>>    note that the choice of compare and swap comes from needing a mnemonic
>>    that matched charlie's initials (CAS). the mnemonic was slightly
>> changed
>>    for inclusion in 370 to CS (compare and swap) and CDS (compare
>> double and swap).
>>
>>    the instructions have since been expanded for 64-bit operation and a
>>    new "perform locked operation" has since been added.
>>
>>
>
> Yup. I have actually conversed with Lynn over on comp.arch. Very smart
> person loaded up with knowledge.

The free pool manipulation in IBM's principle of operations, iirc, its
in an appendix.

Am 04.11.2023 um 17:03 schrieb Scott Lurndal:
> BTW - Compare and Swap was invented by an engineer at IBM -
> ...

The idea is not that complex that it would have been invented by
a lot of technichians later. I think that LL/SC is more sexy since
it allows lock-free stacks with one word.

On 11/4/2023 11:58 AM, Bonita Montero wrote:
> Am 04.11.2023 um 17:03 schrieb Scott Lurndal:
>> BTW - Compare and Swap was invented by an engineer at IBM -
>> ...
>
> The idea is not that complex that it would have been invented by
> a lot of technichians later. I think that LL/SC is more sexy since
> it allows lock-free stacks with one word.
>

Just be careful wrt the reservation granularity. LL/SC can be prone to
livelock.

On 11/4/2023 2:25 AM, Bonita Montero wrote:
> 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's not necessary to record ownership of a specific thread for a non
> recursive mutex but just _that_ a mutex is ownend, and not by whom.
> The benaphore can easily locked in one thread and unlocked in another
> thread, although this usually doesn't happen.
> It's just the surrounding code that successfully locked a mutex that
> "knows" it is the owner.

The surrounding code is the mutex. It can use a kernel semaphore for
slow paths. You seem to be radically confused.

>
>> 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/4/2023 2:17 AM, Bonita Montero wrote:
> Am 03.11.2023 um 23:25 schrieb Chris M. Thomasson:
>
>> On 11/3/2023 10:09 AM, Bonita Montero wrote:
>
>>> 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.
>
> The benaphore does know that it is owned, but not by whom.
> Its the surrounding code that knows that it owns the mutex.

Oh god. The benaphore is a semaphore. Mutex logic using a semaphore for
a slow path is different than a semaphore. God damn, man... You are
confused and/or trolling? Humm...

On 11/4/2023 2:18 AM, Bonita Montero wrote:
> Am 03.11.2023 um 23:18 schrieb Chris M. Thomasson:
>
>> Oh my. A benaphore is basically a userspace semaphore using a kernel
>> semaphore for slow paths.
>
> There isn't sth. like a userspace semaphore since with a sempahore
> you need support to sleep or to be awakened.
>
>

Huh? The point of the benaphore (a semaphore) is to try to avoid going
into the kernel to sleep or to be awakened.

God damn it Bonita!

On 11/4/2023 2:19 AM, Bonita Montero wrote:
> Am 01.11.2023 um 20:59 schrieb Chris M. Thomasson:
>
>> Huh? The benaphore is a semaphore! So, both of you are totally wrong
>> here. Think about it...
>
> Google for "benaphore mutex" and you'll find several refernces that a
> benaphore is a mutex, including the two articles I've referred so far.
>

MORON!!!