Am 06.11.2023 um 05:22 schrieb Kaz Kylheku:

> Umm, nope! Because you can't use a mutex, for instance, in
> signaling "item available" in a producer consumer queue.

So can you make a producer-consumer-queue with a benaphore ?

On 11/5/2023 8:22 PM, Kaz Kylheku wrote:
> On 2023-11-06, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 05.11.2023 um 21:12 schrieb Chris M. Thomasson:
>>> On 11/5/2023 9:55 AM, Bonita Montero wrote:
>>>> Am 05.11.2023 um 18:25 schrieb Kaz Kylheku:
>>>>> On 2023-11-05, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>> google for ... and you'll see a lot of people telling the same
>>>>>> like me.
>>>>>
>>>>> Bandwagon Fallacy
>>>>>
>>>>> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>>>>
>>>> In most cases experts are right if they agree on a certain fact.
>>>>
>>>
>>> Sorry buddy! A benaphore is a semaphore. ...
>>
>> If you take it like that every mutex is also a binary semaphore.
>
> Umm, nope! Because you can't use a mutex, for instance, in
> signaling "item available" in a producer consumer queue.
>
> You can't have a producer doing nothing but unlock(mutex) to signal that
> it has added an item, and a consumer doing nothing but lock(mutex).
>
> If that happens to work, then we know the mutex is really a semaphore.
>
> If it works, but the documentation says that the behavior is undefined,
> we probably shouldn't do that, but use something that is documented.
>
> No mutex provided in any mainstream operating system supports this
> as a documented case that is required to work.
>
> No implementation of POSIX mutexes, not Windows' CRITICAL_SECTION, not
> Win32 Mutexes, not C++ or ISO C mutexes.
>
> You don't care that something is undefined because you're a professional
> troll, not a professional developer.
>

Check out this bakery algorithm I did wrt a multi producer consumer queue:

https://groups.google.com/g/lock-free/c/acjQ3-89abE/m/a6-Di0GZsyEJ

Pretty nice, and can be used with futexes to get rid of the spins.

<pseudo code, membars aside for a moment>
______________________________________________
struct cell { uint32_t ver; double state; };

uint32_t head = 0;
uint32_t tail = 0;
cell cells[N]; // N must be a power of 2

void init() {
for (uint32_t i = 0; i < N; ++i) cells[i].ver = i;
}

void producer(double state) {
uint32_t ver = XADD(&head, 1);
cell& c = cells[ver & (N - 1)];
while (LOAD(&c.ver) != ver) backoff();
c.state = state;
STORE(&c.ver, ver + 1);
}

double consumer() {
uint32_t ver = XADD(&tail, 1);
cell& c = cells[ver & (N - 1)];
while (LOAD(&c.ver) != ver + 1) backoff();
double state = c.state;
STORE(&c.ver, ver + N);
return state;
} ______________________________________________

Pretty elegant logic...

On 11/5/2023 8:37 PM, Bonita Montero wrote:
> Am 06.11.2023 um 05:22 schrieb Kaz Kylheku:
>
>> Umm, nope! Because you can't use a mutex, for instance, in
>> signaling "item available" in a producer consumer queue.
>
> So can you make a producer-consumer-queue with a benaphore ?

Huh? You can use a semaphore to allow a multi producer consumer queue to
wait in the kernel for its slow paths. This is rather basic Bonita. wow.

On 11/5/2023 8:15 PM, Bonita Montero wrote:
> Am 05.11.2023 um 21:12 schrieb Chris M. Thomasson:
>> On 11/5/2023 9:55 AM, Bonita Montero wrote:
>>> Am 05.11.2023 um 18:25 schrieb Kaz Kylheku:
>>>> On 2023-11-05, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> google for ... and you'll see a lot of people telling the same
>>>>> like me.
>>>>
>>>> Bandwagon Fallacy
>>>>
>>>> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>>>
>>> In most cases experts are right if they agree on a certain fact.
>>>
>>
>> Sorry buddy! A benaphore is a semaphore. You, along with the "experts"
>> that try to say that a benaphore is a mutex are 100% completely wrong.
>> Got it?
>
> If you take it that way every mutex is a binary seamphore;
> but no one refers to a mutex as a semaphore.
>

Wtf are you babbling on about!?!?!!?!?

On 11/5/2023 9:02 PM, Chris M. Thomasson wrote:
> On 11/5/2023 8:15 PM, Bonita Montero wrote:
>> Am 05.11.2023 um 21:12 schrieb Chris M. Thomasson:
>>> On 11/5/2023 9:55 AM, Bonita Montero wrote:
>>>> Am 05.11.2023 um 18:25 schrieb Kaz Kylheku:
>>>>> On 2023-11-05, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>> google for ... and you'll see a lot of people telling the same
>>>>>> like me.
>>>>>
>>>>> Bandwagon Fallacy
>>>>>
>>>>> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>>>>
>>>> In most cases experts are right if they agree on a certain fact.
>>>>
>>>
>>> Sorry buddy! A benaphore is a semaphore. You, along with the
>>> "experts" that try to say that a benaphore is a mutex are 100%
>>> completely wrong. Got it?
>>
>> If you take it that way every mutex is a binary seamphore;
>> but no one refers to a mutex as a semaphore.
>>
>
> Wtf are you babbling on about!?!?!!?!?

A mutex is not a semaphore. A semaphore is not a mutex.

:^)

Am 06.11.2023 um 06:00 schrieb Chris M. Thomasson:

> void producer(double state) {
>     uint32_t ver = XADD(&head, 1);
>     cell& c = cells[ver & (N - 1)];
>     while (LOAD(&c.ver) != ver) backoff();
>     c.state = state;
>     STORE(&c.ver, ver + 1);
> }
>
> double consumer() {
>     uint32_t ver = XADD(&tail, 1);
>     cell& c = cells[ver & (N - 1)];
>     while (LOAD(&c.ver) != ver + 1) backoff();
>     double state = c.state;
>     STORE(&c.ver, ver + N);
>     return state;
> }

Lock-free queues are more complex and even if they're implemented
correctly like with boost they suck because they're polled. They
for sure don't make it into the standard.

Am 06.11.2023 um 06:05 schrieb Chris M. Thomasson:

> A mutex is not a semaphore. A semaphore is not a mutex.

A mutex which doesn't maintain the identity of the locking
thread also can be used as a semaphore.

On 11/6/2023 12:36 AM, Bonita Montero wrote:
> Am 06.11.2023 um 06:00 schrieb Chris M. Thomasson:
>
>> void producer(double state) {
>>      uint32_t ver = XADD(&head, 1);
>>      cell& c = cells[ver & (N - 1)];
>>      while (LOAD(&c.ver) != ver) backoff();
>>      c.state = state;
>>      STORE(&c.ver, ver + 1);
>> }
>>
>> double consumer() {
>>      uint32_t ver = XADD(&tail, 1);
>>      cell& c = cells[ver & (N - 1)];
>>      while (LOAD(&c.ver) != ver + 1) backoff();
>>      double state = c.state;
>>      STORE(&c.ver, ver + N);
>>      return state;
>> }
>
> Lock-free queues are more complex and even if they're implemented
> correctly like with boost they suck because they're polled.

What do you mean by that? Why do you _seem_ to think that a lock-free
queue cannot have slow-paths that wait in the kernel?

> They
> for sure don't make it into the standard.

I can get rid of the spin wrt the tickets using futexs. The queue logic
is what I find rather elegant here. Also, I can use a benaphore for
waiting logic. This bounded lock-free queue is pretty damn good.

Btw, there are different queues types.

multi-producer multi-consumer
single-producer multi-consumer

multi-producer single-consumer
single-producer single-consumer

All of them have their trade offs, and they have radically different
algorithms to implement them efficiently.

On 11/6/2023 12:37 AM, Bonita Montero wrote:
> Am 06.11.2023 um 06:05 schrieb Chris M. Thomasson:
>
>> A mutex is not a semaphore. A semaphore is not a mutex.
>
> A mutex which doesn't maintain the identity of the locking
> thread also can be used as a semaphore.
>
>

Barf! A mutex is not a semaphore. However, you can implement a semaphore
using a mutex and condition variables.

On 11/5/2023 12:53 PM, Kaz Kylheku wrote:
> On 2023-11-05, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 05.11.2023 um 18:25 schrieb Kaz Kylheku:
>>> On 2023-11-05, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> google for ... and you'll see a lot of people telling the same
>>>> like me.
>>>
>>> Bandwagon Fallacy
>>>
>>> https://en.wikipedia.org/wiki/Argumentum_ad_populum
>>
>> In most cases experts are right if they agree on a certain fact.
>
> Firstly, "I googled this up" to "experts" is a huge leap.
>
> Secondly, when have you ever recognized or acknowledged expertise?
>

Bonita is the expert? Wow... ;^o

Am 06.11.2023 um 21:11 schrieb Chris M. Thomasson:

> What do you mean by that? Why do you _seem_ to think that a lock-free
> queue cannot have slow-paths that wait in the kernel?

If it is lock-free there's no lock-free any more.

Am 06.11.2023 um 21:13 schrieb Chris M. Thomasson:

> Barf! A mutex is not a semaphore. ...

A mutex which doesn't maintain the caller's identity is a semaphore.

On 2023-11-06, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 06.11.2023 um 21:13 schrieb Chris M. Thomasson:
>
>> Barf! A mutex is not a semaphore. ...
>
> A mutex which doesn't maintain the caller's identity is a semaphore.

We cannot jump to that conclusion.

To use a mutex a a semaphore, we map the unlock operation to signal
and lock to wait.

It must be possible to signal multiple times.

If the mutex object rejects the unlock operation if it is already
in an unlocked state (for instance, by terminating the process with an
assertion) then it cannot function as a semaphore.

I suggest you abandon this fruitless exercise and let semaphores
be semaphores and mutexes be mutexes.

They are different things and we have different words for them,
which is useful; don't try to wreck 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.

Am 07.11.2023 um 00:00 schrieb Kaz Kylheku:

> To use a mutex a a semaphore, we map the unlock operation to signal
> and lock to wait.

If you have a mutex that doesn't memorize who's the locking thread
a lock() is an acquire() and an unlock() is a release().

On 2023-11-07, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 07.11.2023 um 00:00 schrieb Kaz Kylheku:
>
>> To use a mutex a a semaphore, we map the unlock operation to signal
>> and lock to wait.
>
> If you have a mutex that doesn't memorize who's the locking thread
> a lock() is an acquire() and an unlock() is a release().

That does not follow. Sure; not memorizing the locking thread
does remove one roadblock.

Not having an owner appears to be is a necessary condition.

You're not distinguishing between necessary and sufficient conditions.

--
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 07.11.2023 um 06:29 schrieb Kaz Kylheku:

> That does not follow. Sure; not memorizing the locking thread
> does remove one roadblock.
> Not having an owner appears to be is a necessary condition.
> You're not distinguishing between necessary and sufficient conditions.

It the mutex doesn't track the owner, specified or not,
it's a binary semaphore.

On 11/6/2023 2:52 PM, Bonita Montero wrote:
> Am 06.11.2023 um 21:11 schrieb Chris M. Thomasson:
>
>> What do you mean by that? Why do you _seem_ to think that a lock-free
>> queue cannot have slow-paths that wait in the kernel?
>
> If it is lock-free there's no lock-free any more.
>
>

It is basically morphing any lock-free algorithm into something that has
fast-paths that avoid the kernel, and slow paths the make use of the
kernel. Imho, it's interesting to do.

On 11/7/2023 12:38 AM, Bonita Montero wrote:
> Am 07.11.2023 um 06:29 schrieb Kaz Kylheku:
>
>> That does not follow. Sure; not memorizing the locking thread
>> does remove one roadblock.
>> Not having an owner appears to be is a necessary condition.
>> You're not distinguishing between necessary and sufficient conditions.
>
> It the mutex doesn't track the owner, specified or not,
> it's a binary semaphore.

Still wrong.

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

Got to get very intimate, like how a mutex is very intimate wrt a
condition variable... ;^)

On 11/5/2023 8:16 PM, Bonita Montero wrote:
> Am 06.11.2023 um 05:10 schrieb Chris M. Thomasson:
>>
>> Nope. Wow, you massively confused! A mutex does not need to use
>> semaphore logic, it can have its own fast path algorithm, XCHG for
>> instance. ...
>
> With pure userland-logic you won't have the opportunity to sleep for
> a mutex or to be awakened.

I want to say Bontia == Dr. Trolls-a-LOT?

On 11/7/2023 12:38 AM, Bonita Montero wrote:
> Am 07.11.2023 um 06:29 schrieb Kaz Kylheku:
>
>> That does not follow. Sure; not memorizing the locking thread
>> does remove one roadblock.
>> Not having an owner appears to be is a necessary condition.
>> You're not distinguishing between necessary and sufficient conditions.
>
> It the mutex doesn't track the owner, specified or not,
> it's a binary semaphore.
>
>

https://youtu.be/cvg5mbM6FGs?t=161

Am 07.11.2023 um 20:53 schrieb Chris M. Thomasson:

> On 11/7/2023 12:38 AM, Bonita Montero wrote:

>> It the mutex doesn't track the owner, specified or not,
>> it's a binary semaphore.

> Still wrong.

No, absolutely true. If you have a mutex which doesn't track
the owning thread you're not mandated to release it in the
same thread.

On 11/8/2023 8:49 PM, Bonita Montero wrote:
> Am 07.11.2023 um 20:53 schrieb Chris M. Thomasson:
>
>> On 11/7/2023 12:38 AM, Bonita Montero wrote:
>
>>> It the mutex doesn't track the owner, specified or not,
>>> it's a binary semaphore.
>
>> Still wrong.
>
> No, absolutely true. If you have a mutex which doesn't track
> the owning thread you're not mandated to release it in the
> same thread.
>

Mutex != Semaphore

Am 09.11.2023 um 05:52 schrieb Chris M. Thomasson:

> Mutex != Semaphore

A mutex which doesn't track the owning thread is functionally
a semaphore.

On 11/8/2023 8:54 PM, Bonita Montero wrote:
> Am 09.11.2023 um 05:52 schrieb Chris M. Thomasson:
>
>> Mutex != Semaphore
>
> A mutex which doesn't track the owning thread is functionally
> a semaphore.

Barf! I almost puked. Thanks, Bonita. ;^o