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.

On 10/30/2023 12:12 AM, Bonita Montero 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:
[...]

Test out the benaphore:

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

Am 30.10.2023 um 21:08 schrieb Chris M. Thomasson:

> On 10/30/2023 12:12 AM, Bonita Montero 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:
> [...]

> Test out the benaphore:
> https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26

I think this guy never heard of how a usual mutex works and re-invented
the wheel and called it a benaphore.

On 2023-10-31, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 30.10.2023 um 21:08 schrieb Chris M. Thomasson:
>
>> On 10/30/2023 12:12 AM, Bonita Montero 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:
>> [...]
>
>> Test out the benaphore:
>> https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
>
> I think this guy never heard of how a usual mutex works and re-invented
> the wheel and called it a benaphore.
>
formatt elf64

FUTEX_WAIT equ 0
FUTEX_WAKE equ 1
FUTEX_PRIVATE_FLAG equ 128

public futex_acquire
public futex_release

futex_acquire:
push rbx
push r15
; push r10
mov r15,rdi
..L0:
mov ebx,1
xor eax,eax
lock cmpxchg [r15],ebx
test eax,eax
jz .L1
mov eax, 202
mov rdi, r15
mov rsi, FUTEX_WAIT or FUTEX_PRIVATE_FLAG
mov edx, 1
xor r10,r10
syscall
jmp .L0
..L1:; pop r10
pop r15
pop rbx
ret

futex_release:
lock and dword[rdi],0
mov eax,202
; mov rdi, sema
mov rsi, FUTEX_WAKE or FUTEX_PRIVATE_FLAG
mov edx,1
syscall
ret

---------
x86 mutex on linux

--

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

On 10/31/2023 5:25 AM, Bonita Montero wrote:
> Am 30.10.2023 um 21:08 schrieb Chris M. Thomasson:
>
>> On 10/30/2023 12:12 AM, Bonita Montero 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:
>> [...]
>
>> Test out the benaphore:
>> https://www.haiku-os.org/legacy-docs/benewsletter/Issue1-26.html#Engineering1-26
>
> I think this guy never heard of how a usual mutex works and re-invented
> the wheel and called it a benaphore.
>

Why do you say that?

Am 31.10.2023 um 21:59 schrieb Chris M. Thomasson:

> On 10/31/2023 5:25 AM, Bonita Montero wrote:

>> I think this guy never heard of how a usual mutex works
>> and re-invented the wheel and called it a benaphore.

> Why do you say that?

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.

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.

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.

Am 01.11.2023 um 19:24 schrieb Bonita Montero:

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

I found that LOCK XADD was introduced 1990 with the i486.
I think the designers of this instruction had this specific
kind of mutex in mind.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 01.11.2023 um 19:24 schrieb Bonita Montero:
>
>> 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.
>
>I found that LOCK XADD was introduced 1990 with the i486.

Multiprocessor computer systems existed long before the i486;
nothing the 486 did was new.

Burroughs mainframes had mutexes and condition variables in the
1970s (during which time Dijkstra was a Burroughs fellow).

A great deal of research on synchronization was done in the
60s and 1970s, including work by Lamport, Hoare, Dijkstra
and others.

I always found Hoare's Co-operating Sequential Processes interesting,
here's his book (not pirated):

http://www.usingcsp.com/

The book is based on his 197x paper we studied in school.

Am 01.11.2023 um 20:04 schrieb Scott Lurndal:

> Bonita Montero <Bonita.Montero@gmail.com> writes:

>> I found that LOCK XADD was introduced 1990 with the i486.

> Multiprocessor computer systems existed long before the i486;
> nothing the 486 did was new.

I treaded the indroduction of LOCK XADD just as a hint that sth.
like this benaphore was thoguht before 1996.

On 11/1/2023 5:00 AM, Bonita Montero wrote:
> Am 31.10.2023 um 21:59 schrieb Chris M. Thomasson:
>
>> On 10/31/2023 5:25 AM, Bonita Montero wrote:
>
>>> I think this guy never heard of how a usual mutex works
>>> and re-invented the wheel and called it a benaphore.
>
>> Why do you say that?
>
> 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.
>

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?

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

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

Its a semaphore, not a mutex. Any semaphore can be used for a mutex, hint:

Binary Semaphore

On 11/1/2023 12:11 PM, Bonita Montero wrote:
> Am 01.11.2023 um 20:04 schrieb Scott Lurndal:
>
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>>> I found that LOCK XADD was introduced 1990 with the i486.
>
>> Multiprocessor computer systems existed long before the i486;
>> nothing the 486 did was new.
>
> I treaded the indroduction of LOCK XADD just as a hint that sth.
> like this benaphore was thoguht before 1996.

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.
Think, strong CAS vs weak CAS...

On 2023-11-01, 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 back then, Ben Affleck had a hotly publicized affair with a hot
water bottle (thermophore), so that's where that's from.

--
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/1/2023 1:50 PM, Kaz Kylheku wrote:
> On 2023-11-01, 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 back then, Ben Affleck had a hotly publicized affair with a hot
> water bottle (thermophore), so that's where that's from.
>

LOL! :^D

On 11/1/2023 1:50 PM, Kaz Kylheku wrote:
> On 2023-11-01, 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 back then, Ben Affleck had a hotly publicized affair with a hot
> water bottle (thermophore), so that's where that's from.
>

Be sure to check out:

https://vorbrodt.blog/2019/02/05/fast-semaphore

;^)

Am 01.11.2023 um 21:01 schrieb Chris M. Thomasson:
> On 11/1/2023 11:24 AM, Bonita Montero 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.
>>
>
> Its a semaphore, not a mutex. Any semaphore can be used for a mutex, hint:

You can say that each binary semaphore is a mutex. And a semaphore
is usually not a compound of userland and kernel facilities, but a
pure kernel resource.

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.

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.

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.

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

A semaphore can be used as a mutex, but it isn't one.

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

A semaphore restricted to binary values can still serve as a mutex for
the reason that a mutex is never unlocked multiple times in a correct
program. So if we correctly use a semaphore as a mutex, its count should
never go over 1, and for that reason, we can get away with using
semaphore that only counts from 0 to 1.

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

The idea that a semaphore represents a locked state, which has an
associated owner, arise purely by the situational convention of how it
is applied.

A semaphore couldn't provide error checking, such as when a mutex
non-owner tries to unlock, or recursive deadlock detection.

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

Am 02.11.2023 um 16:34 schrieb David Brown:

> 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.  Thismakes them very
> distinctly different on such OS's - a mutex is a lock, a semaphore
> (binary or otherwise) is a signalling mechanism.

Does Linux actually boost thread priorities with mutexes ?