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:
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.
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 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?
Why do you say that?
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 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 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.
Bonita Montero <[email protected]> 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.
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 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 01.11.2023 um 20:04 schrieb Scott Lurndal:
Bonita Montero <[email protected]> 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.
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 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.
On 2023-11-01, Bonita Montero <[email protected]> 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.
On 2023-11-01, Bonita Montero <[email protected]> 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.
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:
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.
Bonita Montero <[email protected]> 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.
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.
Firstly, it doesn't have to be binary to be used as a mutex.
A semaphore isn't a mutex because it doesn't incorporate the concept
of lock ownership.
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.
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.
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.
Locked isn't necessarily owned.
The semaphore does not record the ID of an owner.
On 02/11/2023 15:58, Scott Lurndal wrote:
Bonita Montero <[email protected]> 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 <[email protected]> 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.
On 11/2/2023 8:34 AM, David Brown wrote:
On 02/11/2023 15:58, Scott Lurndal wrote:
Bonita Montero <[email protected]> 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.)
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 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. ...
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-02, Bonita Montero <[email protected]> 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.
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 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.
Semophores can be efficiently implemented on "old" x86 by means of
'LOCK ADD mem, reg'. ...
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.
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.
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, ...
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 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.
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.
On 2023-11-03, Bonita Montero <[email protected]> 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.
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."
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. ...
Bonita Montero <[email protected]> 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.
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.
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.
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.
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 <[email protected]> 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 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.
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.
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.
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.
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.
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.
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.
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 <[email protected]> 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.)
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.
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 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.
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 <[email protected]> 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.
Bonita Montero <[email protected]> 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.
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/
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/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 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.
An atomic counter, featuring a wait when the value is in a certain
range, is known as semaphore.
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
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.
Oh my. A benaphore is basically a userspace semaphore using a kernel semaphore for slow paths.
Huh? The benaphore is a semaphore! So, both of you are totally wrong
here. Think about it...
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 2023-10-30, Bonita Montero <[email protected]> wrote:
MSVC's C++20 semaphore class spins to acquire the semaphore;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]
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.
};
^
1 warning generated.
bmaxa@Branimirs-MacBook-Air News % ./run
libc++abi: terminating
zsh: abort ./run
Google for "benaphore mutex" ...Or rather "benaphore mutex -semaphore".
"Chris M. Thomasson" <[email protected]> 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.
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.
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.
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.
I think, from this thread, it is clear that you have no idea how mutexes
are used. ...
I stand corrected. Your idea of "usually" is limited to no OS in
existence.
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 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.
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.
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.
"Chris M. Thomasson" <[email protected]> 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.
"Chris M. Thomasson" <[email protected]> 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.
On 11/4/2023 9:03 AM, Scott Lurndal wrote:
"Chris M. Thomasson" <[email protected]> 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.
BTW - Compare and Swap was invented by an engineer at IBM -
...
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.
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 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: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 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.
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!!!
On 11/4/2023 12:51 PM, Chris M. Thomasson wrote:
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!!!
The benaphore is a semaphore using a bakery algorithm. You are
completely confused and incoherently flailing around.
On Thu, 2 Nov 2023 16:02:04 -0000 (UTC)
Kaz Kylheku <[email protected]> wrote:
On 2023-11-02, Bonita Montero <[email protected]> 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.
The surrounding code is the mutex. ...
Oh god. The benaphore is a semaphore. ...
The surrounding code is the mutex. ...
On 11/3/2023 7:10 AM, Michael S wrote:
On Thu, 2 Nov 2023 16:02:04 -0000 (UTC)
Kaz Kylheku <[email protected]> wrote:
On 2023-11-02, Bonita Montero <[email protected]> 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.
mutual exclusion?
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.
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
On 2023-11-05, Bonita Montero <[email protected]> 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
google for ... and you'll see a lot of people telling the same
like me.
Am 04.11.2023 um 20:42 schrieb Chris M. Thomasson:
The surrounding code is the mutex. ...
You didn't understand me. The surrounding code that operates
on the guarded data structure isn't the mutex.
Am 05.11.2023 um 18:25 schrieb Kaz Kylheku:
On 2023-11-05, Bonita Montero <[email protected]> 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.
On 11/4/2023 12:53 PM, Chris M. Thomasson wrote:
On 11/4/2023 12:51 PM, Chris M. Thomasson wrote:
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!!!
The benaphore is a semaphore using a bakery algorithm. You are
completely confused and incoherently flailing around.
https://vorbrodt.blog/2019/02/05/fast-semaphore
Am 05.11.2023 um 18:25 schrieb Kaz Kylheku:
On 2023-11-05, Bonita Montero <[email protected]> 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.
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 <[email protected]> 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?
Actually, an "expert" that tries to say that a benaphore is a mutex
should be FIRED on the spot.
On 11/4/2023 9:35 PM, Bonita Montero wrote:
Am 04.11.2023 um 20:42 schrieb Chris M. Thomasson:
The surrounding code is the mutex. ...
You didn't understand me. The surrounding code that operates
on the guarded data structure isn't the mutex.
Any semaphore can be used as a binary semaphore, which can in turn be
used for mutual exclusion. Now, the mutex logic itself can record what
thread has ownership, ect... This is separate from the semaphore logic.
Are you sure that you are not misunderstanding me?
On 2023-11-05, Chris M. Thomasson <[email protected]> wrote:
Actually, an "expert" that tries to say that a benaphore is a mutex
should be FIRED on the spot.
They probably are; just not from the Google search index.
On 2023-11-05, Chris M. Thomasson <[email protected]> wrote:
On 11/4/2023 9:35 PM, Bonita Montero wrote:
Am 04.11.2023 um 20:42 schrieb Chris M. Thomasson:
The surrounding code is the mutex. ...
You didn't understand me. The surrounding code that operates
on the guarded data structure isn't the mutex.
Any semaphore can be used as a binary semaphore, which can in turn be
used for mutual exclusion. Now, the mutex logic itself can record what
thread has ownership, ect... This is separate from the semaphore logic.
Are you sure that you are not misunderstanding me?
It's like someone paid to misunderstand ... only minus any actual money.
On 11/5/2023 2:54 PM, Kaz Kylheku wrote:
On 2023-11-05, Chris M. Thomasson <[email protected]> wrote:
On 11/4/2023 9:35 PM, Bonita Montero wrote:
Am 04.11.2023 um 20:42 schrieb Chris M. Thomasson:
The surrounding code is the mutex. ...
You didn't understand me. The surrounding code that operates
on the guarded data structure isn't the mutex.
Any semaphore can be used as a binary semaphore, which can in turn be
used for mutual exclusion. Now, the mutex logic itself can record what
thread has ownership, ect... This is separate from the semaphore logic.
Are you sure that you are not misunderstanding me?
It's like someone paid to misunderstand ... only minus any actual money.
Humm... Interesting comment! Almost hard to disagree with wrt the, Bontia...
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 <[email protected]> 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.
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 <[email protected]> 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. ...
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 <[email protected]> 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?
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. ...
Umm, nope! Because you can't use a mutex, for instance, in
signaling "item available" in a producer consumer queue.
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 <[email protected]> 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.
On 2023-11-06, Bonita Montero <[email protected]> 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 <[email protected]> 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.
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 ?
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 <[email protected]> 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.
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 <[email protected]> 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.
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;
}
On 2023-11-05, Bonita Montero <[email protected]> wrote:
Am 05.11.2023 um 18:25 schrieb Kaz Kylheku:
On 2023-11-05, Bonita Montero <[email protected]> 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?
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.
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?
Barf! A mutex is not a semaphore. ...
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.
To use a mutex a a semaphore, we map the unlock operation to signal
and lock to wait.
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.
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.
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.
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 <[email protected]> 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.)
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.
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/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.
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/4/2023 8:53 AM, Scott Lurndal wrote:
"Chris M. Thomasson" <[email protected]> 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 43:33:26 |
| Calls: | 12,111 |
| Calls today: | 2 |
| Files: | 15,008 |
| Messages: | 6,518,440 |