Chris M. Thomasson wrote:
> On 9/30/2023 12:32 PM, Michael S wrote:
>> On Saturday, September 30, 2023 at 10:07:57 PM UTC+3, Kaz Kylheku wrote:
>>> On 2023-09-30, Bonita Montero <Bonita....@gmail.com> wrote:
>>>> Am 30.09.2023 um 05:57 schrieb Pavel:
>>>>> Bonita Montero wrote:
>>>>>> Am 29.09.2023 um 03:46 schrieb Pavel:
>>>>>>
>>>>>>> see my or Kaz's explanation for how it is done without allocating
>>>>>>> any
>>>>>>> kernel resource on either initialization or locking, either fast or
>>>>>>> slow path.
>>>>>>
>>>>>> ... on Linux with signals.
>>>>>>
>>>>> With user-space sync primitives on any system.
>>>>
>>>> A mutex may lead to a sleeping thread, that's only possible with
>>>> the help of the kernel.
>>> You keep returning to this in circles, forgetting that the argument
>>> isn't that help from the kernel isn't required.
>>>
>>> The argument is that there is no need to allocate a kernel
>>> object per mutex. That is only one point in the design space,
>>> and not a very good one.
>>>
>>> Do *you* have ADHD is the question.
>>> --
>>> TXR Programming Language: http://nongnu.org/txr
>>> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
>>> Mastodon: @Kazi...@mstdn.ca
>>> NOTE: If you use Google Groups, I don't see you, unless you're
>>> whitelisted.
>>
>> Another point is that "one user-mode lock per one local static object"
>> is also only one point in the design space. Possibly, not a bad point, if
>> you have user-mode lock as small as futex on Linux or  or even as
>> (slightly
>> bigger) SRW Lock on Windows's, but it seems that none of major C++
>> toolsets
>> had chosen this particular design point. I don't know why.
>>
>
> Actually, one of my rw mutex algorithms allocates all of its kernel
> resources up front wrt the object itself. So, the rwmutex can report
> this condition wrt failure to create a kernel semaphore, in its
> constructor, not on a damn lock() op wrt contention.
>
> Fwiw, a person was kind enough to use my rwmutex work here: Notice it
> has no loops? :^)
Neat.

Just curious: why do you sometimes use fetch_add with negative addend
and sometimes fetch_sub?

>
> https://vorbrodt.blog/2019/02/14/read-write-mutex/
> (check it out...)
>
> Btw, I have modeled this using several race detectors even though I know
> it works. :^)

On 9/30/2023 6:09 PM, Pavel wrote:
> Chris M. Thomasson wrote:
>> On 9/30/2023 12:32 PM, Michael S wrote:
>>> On Saturday, September 30, 2023 at 10:07:57 PM UTC+3, Kaz Kylheku wrote:
>>>> On 2023-09-30, Bonita Montero <Bonita....@gmail.com> wrote:
>>>>> Am 30.09.2023 um 05:57 schrieb Pavel:
>>>>>> Bonita Montero wrote:
>>>>>>> Am 29.09.2023 um 03:46 schrieb Pavel:
>>>>>>>
>>>>>>>> see my or Kaz's explanation for how it is done without
>>>>>>>> allocating any
>>>>>>>> kernel resource on either initialization or locking, either fast or
>>>>>>>> slow path.
>>>>>>>
>>>>>>> ... on Linux with signals.
>>>>>>>
>>>>>> With user-space sync primitives on any system.
>>>>>
>>>>> A mutex may lead to a sleeping thread, that's only possible with
>>>>> the help of the kernel.
>>>> You keep returning to this in circles, forgetting that the argument
>>>> isn't that help from the kernel isn't required.
>>>>
>>>> The argument is that there is no need to allocate a kernel
>>>> object per mutex. That is only one point in the design space,
>>>> and not a very good one.
>>>>
>>>> Do *you* have ADHD is the question.
>>>> --
>>>> TXR Programming Language: http://nongnu.org/txr
>>>> Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
>>>> Mastodon: @Kazi...@mstdn.ca
>>>> NOTE: If you use Google Groups, I don't see you, unless you're
>>>> whitelisted.
>>>
>>> Another point is that "one user-mode lock per one local static object"
>>> is also only one point in the design space. Possibly, not a bad
>>> point, if
>>> you have user-mode lock as small as futex on Linux or  or even as
>>> (slightly
>>> bigger) SRW Lock on Windows's, but it seems that none of major C++
>>> toolsets
>>> had chosen this particular design point. I don't know why.
>>>
>>
>> Actually, one of my rw mutex algorithms allocates all of its kernel
>> resources up front wrt the object itself. So, the rwmutex can report
>> this condition wrt failure to create a kernel semaphore, in its
>> constructor, not on a damn lock() op wrt contention.
>>
>> Fwiw, a person was kind enough to use my rwmutex work here: Notice it
>> has no loops? :^)
> Neat.
>
> Just curious: why do you sometimes use fetch_add with negative addend
> and sometimes fetch_sub?

Good question. Well, iirc, way back when I was experimenting and
designing it I wanted to test fetch_add _and_ fetch_sub with Relacy
which was in its fairly early stages then. I had _pure_ loopless bakery
algorithms on my mind for some other interesting reasons... Anyway, my
original code used all fetch_add, but I altered it to use fetch_sub into
the unit testing.

I was originally building this on an x86, and using all LOCK XADD's.

When I presented it, iirc, I accidentally showed my Relacy code that had
fetch_sub. This is not exactly consistent! But I just said, ahhh okay,
it still works. Sorry about that. It's me forgetting that I used
fetch_sub in one of my unit tests, and forgot to change them back
_before_ I presented it. Argh! ;^o

Actually, I can kind of remember when I actually altered a single
fetch_add to fetch_sub in one place:
_____________
[...]
if (m_wrstate.fetch_sub(1, std::memory_order_acquire) < 1)
[...]
_____________

Which can be replaced with:
_____________
[...]
if (m_wrstate.fetch_add(-1, std::memory_order_acquire) < 1)
[...]
_____________

It's nice that you noticed it! Bringing back memories.

Just one of my bakery algorithm experiments. I posted it way back over
on the intel threading forums, but that group does not seem to exist or
has changed over the years. Thanks for the memories, Pavel! Thanks for
taking an interesting interest. :^)

Fwiw, this also brings back memories about strong CAS and weak CAS.
Strong CAA can be used in a loopless bakery algorithm, but not
necessarily with weak. Weak can fail spuriously and require a loop. This
loop would break my loopless requirements. Also, I remember putting a
restriction on myself that I have to do it without using CAS at all,
weak or strong! :^)

Btw, my rwmutex has a pretty decent and rather slim read lock/unlock...

:^D

Weak vs Strong CAS is an interesting topic in and of itself.

>
>>
>> https://vorbrodt.blog/2019/02/14/read-write-mutex/
>> (check it out...)
>>
>> Btw, I have modeled this using several race detectors even though I
>> know it works. :^)
>

Am 30.09.2023 um 20:06 schrieb Pavel:

> This does not prove that the kernel call to acquire the primitive may
> fail. ...

This has not to be proven, but this has to be assumed by the standard.
mutex::lock() can throw system_error for that:

Rest unread.

Am 30.09.2023 um 21:07 schrieb Kaz Kylheku:

> You keep returning to this in circles, forgetting that the argument
> isn't that help from the kernel isn't required.

On Linux. On Windows the kernel handle for the thread might have been
closed so you have no other way to sleep than for an event or semaphore.

On 2023-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 30.09.2023 um 21:07 schrieb Kaz Kylheku:
>
>> You keep returning to this in circles, forgetting that the argument
>> isn't that help from the kernel isn't required.
>
> On Linux.

What on Linux? The argument isn't that help from the kernel isn't
required. It is, on Linux and Windows.

> On Windows the kernel handle for the thread might have been
> closed so you have no other way to sleep than for an event or semaphore.

What? Who said anything about a thread handle? How does this relate
to anything? A "handle per thread" isn't a handle to the thread.

--
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 01.10.2023 um 18:41 schrieb Kaz Kylheku:

> What on Linux? The argument isn't that help from the kernel isn't
> required. It is, on Linux and Windows.

If you want to go to sleep while another contender holds the lock
you need the kernel.

On 2023-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 01.10.2023 um 18:41 schrieb Kaz Kylheku:
>
>> What on Linux? The argument isn't that help from the kernel isn't
>> required. It is, on Linux and Windows.
>
> If you want to go to sleep while another contender holds the lock
> you need the kernel.

I have no idea why you're repeating my point, but okay.

Maybe the double negative in that first sentence went over your head?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/1/23 1:00 AM, Bonita Montero wrote:
> Am 30.09.2023 um 20:06 schrieb Pavel:
>
>> This does not prove that the kernel call to acquire the primitive may
>> fail. ...
>
> This has not to be proven, but this has to be assumed by the standard.
> mutex::lock() can throw system_error for that:

No, the Standard establishes the rules, and the standard say that the
static initialization synchronization can't fail, so if std::mutex might
fail for this sort of lock, the implementation can't use a std::mutex to
do that synchronization.

Until you can show an actual case of an inplementation which has the
power to actually correctly run threaded code, that can't achieve this
syncronization, you are just proving you don't beleive code should be
correct.

>
> Rest unread.

Which just proves your stupidity.

Am 01.10.2023 um 19:18 schrieb Richard Damon:

> No, the Standard establishes the rules, and the standard say that the
> static initialization synchronization can't fail, so if std::mutex might
> fail for this sort of lock, the implementation can't use a std::mutex to
> do that synchronization.

But the standard should mandate that this might fail and throw
a system_error to work with any conditions.

Rest unread.

On 10/1/23 3:03 PM, Bonita Montero wrote:
> Am 01.10.2023 um 19:18 schrieb Richard Damon:
>
>> No, the Standard establishes the rules, and the standard say that the
>> static initialization synchronization can't fail, so if std::mutex
>> might fail for this sort of lock, the implementation can't use a
>> std::mutex to do that synchronization.
>
> But the standard should mandate that this might fail and throw
> a system_error to work with any conditions.
>
> Rest unread.
>

Why? You don't seem to understand how Stzndards work, and are just
ADMITTING to being ignorant.

YOUR LOSS.

The standard ALLOWS a mutex lock to fail, as there are operating
conditions when this might happen, either due to "misuse" of the Mutex,
or making a stronger inter-process mutex that needs system resources.

Static initialization just isn't allowed to use such broken methods.

Thank you for letting the world know that we can not trust any program
that you create, as you don't understand that programs need to do what
they are supposed to do.

Bonita Montero wrote:
> Am 30.09.2023 um 20:06 schrieb Pavel:
>
>> This does not prove that the kernel call to acquire the primitive may
>> fail. ...
>
> This has not to be proven, but this has to be assumed by the standard.
> mutex::lock() can throw system_error for that:
Nope. The standard never says this specifically about mutex::lock. Only
about all mutices collectively. Then about every other mutex *apart
from* std::mutex. Regardless, even the standards says that about
std::mutex, this would still not mean that C++ variable initialization
may throw system_error because the standard never says that such
initialization shall be implemented using std::mutex.

>
> Rest unread.
One more broken promise?

Am 01.10.2023 um 21:45 schrieb Richard Damon:

> Static initialization just isn't allowed to use such broken methods.

That's not my opinion that this is a less method.
It's not more broken than a failing mutex.

Am 02.10.2023 um 01:19 schrieb Pavel:

> Nope. The standard never says this specifically about mutex::lock. ...

Of course, mutex::lock() may throw a system_error.

On Wednesday, September 6, 2023 at 7:15:29 PM UTC+1, Bonita Montero wrote:
>
> With C++11 static local or global data is initialized thread-safe.
> This is usually done with double checked locking (DCL). DCL needs
> a flag along with the static data which shows if the data already
> is initialized and a mutex which guards the initalization.
> I assumed that an implementation simply would use a central mutex
> for all static data objects since it includes a kernel semaphore,
> which is a costly resource.

In the following sample code, I would expect the implementations of Func1 and Func2 to be very similar, except that Func2 would also need to set a global flag somewhere indicating that 'myvec' should have its destructor called.

https://godbolt.org/z/1vcE6MEeK

Am 02.10.2023 um 13:39 schrieb Frederick Virchanza Gotham:

> In the following sample code, I would expect the implementations of Func1 and Func2 to be very similar, except that Func2 would also need to set a global flag somewhere indicating that 'myvec' should have its destructor called.

static initialization of non-trivial types is usually done
with DCL - no need to instantiate the object yourself.

On 10/1/23 11:50 PM, Bonita Montero wrote:
> Am 01.10.2023 um 21:45 schrieb Richard Damon:
>
>> Static initialization just isn't allowed to use such broken methods.
>
> That's not my opinion that this is a less method.
> It's not more broken than a failing mutex.
>

So, you admit that you don't mind you code being broken.

Thanks for letting the world know.

Am 02.10.2023 um 13:56 schrieb Richard Damon:

> On 10/1/23 11:50 PM, Bonita Montero wrote:

>> That's not my opinion that this is a less method.
>> It's not more broken than a failing mutex.

> So, you admit that you don't mind you code being broken.

No, I wouldn't consider that as broken.

On 10/2/23 8:00 AM, Bonita Montero wrote:
> Am 02.10.2023 um 13:56 schrieb Richard Damon:
>
>> On 10/1/23 11:50 PM, Bonita Montero wrote:
>
>>> That's not my opinion that this is a less method.
>>> It's not more broken than a failing mutex.
>
>> So, you admit that you don't mind you code being broken.
>
> No, I wouldn't consider that as broken.
>

So, you don't know that you code is broken?

Am 02.10.2023 um 14:04 schrieb Richard Damon:

> On 10/2/23 8:00 AM, Bonita Montero wrote:

>> No, I wouldn't consider that as broken.

> So, you don't know that you code is broken?

For me it wouldn't be broken since the scope of the object whose
inintialization is failed is also left, so that the object can't
be addressed.

On 10/2/2023 5:04 AM, Richard Damon wrote:
> On 10/2/23 8:00 AM, Bonita Montero wrote:
>> Am 02.10.2023 um 13:56 schrieb Richard Damon:
>>
>>> On 10/1/23 11:50 PM, Bonita Montero wrote:
>>
>>>> That's not my opinion that this is a less method.
>>>> It's not more broken than a failing mutex.
>>
>>> So, you admit that you don't mind you code being broken.
>>
>> No, I wouldn't consider that as broken.
>>
>
> So, you don't know that you code is broken?

Most likely?

Bonita Montero wrote:
> Am 02.10.2023 um 01:19 schrieb Pavel:
>
>> Nope. The standard never says this specifically about mutex::lock. ...
>
> Of course, mutex::lock() may throw a system_error.
>
The standard does not say that; but, even if it did, it wouldn't follow
it needed to permit C++ static initialization throw system_error.

Bonita Montero wrote:
> Am 02.10.2023 um 13:39 schrieb Frederick Virchanza Gotham:
>
>> In the following sample code, I would expect the implementations of
>> Func1 and Func2 to be very similar, except that Func2 would also need
>> to set a global flag somewhere indicating that 'myvec' should have its
>> destructor called.
>
> static initialization of non-trivial types is usually done
> with DCL - no need to instantiate the object yourself.
>
What is a "non-trivial" type and where did you find it initialized in
the code by Frederick?

On 10/2/2023 7:24 PM, Pavel wrote:
> Bonita Montero wrote:
>> Am 02.10.2023 um 01:19 schrieb Pavel:
>>
>>> Nope. The standard never says this specifically about mutex::lock. ...
>>
>> Of course, mutex::lock() may throw a system_error.
>>
> The standard does not say that; but, even if it did, it wouldn't follow
> it needed to permit C++ static initialization throw system_error.

Bonita must be referring to:

https://cplusplus.com/reference/mutex/mutex/lock/

Read carefully:
_____________________________
Exception safety
Basic guarantee: if an exception is thrown by this member function, the
mutex object is left in a valid state. Further, a lock is never acquired
by the thread that made the throwing call.
If the mutex is already locked by the current thread, calling this
function causes a deadlock (undefined behavior): on certain library
implementations, this causes the function to fail.

If the call fails, a system_error exception is thrown:
exception type error condition description
system_error errc::resource_deadlock_would_occur A deadlock was detected
(implementations may detect certain cases of deadlock).
system_error errc::operation_not_permitted The thread does not have
privileges to perform the operation.
system_error errc::device_or_resource_busy The native handle type
manipulated is already locked.
Depending on the library implementation, this member function may also
throw exceptions to report other situations.
_____________________________

Basically, undefined behavior and bad user code causes the function to
fail, robust mutex aside for a moment. It kind of sorta seems like some
of Bonita's code must be saturated with undefined behavior, so it must
try to handle it somehow... I know, it says out loud, lets change the
standard! Oh shit.... Yikes!

Chris M. Thomasson wrote:
> On 10/2/2023 7:24 PM, Pavel wrote:
>> Bonita Montero wrote:
>>> Am 02.10.2023 um 01:19 schrieb Pavel:
>>>
>>>> Nope. The standard never says this specifically about mutex::lock. ...
>>>
>>> Of course, mutex::lock() may throw a system_error.
>>>
>> The standard does not say that; but, even if it did, it wouldn't
>> follow it needed to permit C++ static initialization throw system_error.
>
> Bonita must be referring to:
>
> https://cplusplus.com/reference/mutex/mutex/lock/
>
> Read carefully:
> _____________________________
> Exception safety
> Basic guarantee: if an exception is thrown by this member function, the
> mutex object is left in a valid state. Further, a lock is never acquired
> by the thread that made the throwing call.
> If the mutex is already locked by the current thread, calling this
> function causes a deadlock (undefined behavior): on certain library
> implementations, this causes the function to fail.
>
> If the call fails, a system_error exception is thrown:
> exception type    error condition    description
> system_error    errc::resource_deadlock_would_occur    A deadlock was
> detected (implementations may detect certain cases of deadlock).
> system_error    errc::operation_not_permitted    The thread does not
> have privileges to perform the operation.
> system_error    errc::device_or_resource_busy    The native handle type
> manipulated is already locked.
> Depending on the library implementation, this member function may also
> throw exceptions to report other situations.
> _____________________________
>
>
> Basically, undefined behavior and bad user code causes the function to
> fail, robust mutex aside for a moment. It kind of sorta seems like some
> of Bonita's code must be saturated with undefined behavior, so it must
> try to handle it somehow... I know, it says out loud, lets change the
> standard! Oh shit.... Yikes!
Well, this is not the standard. The standards says, literally:

------ cut here ---------
33.6.4
1 1
Mutex requirements
[thread.mutex.requirements]
33.6.4.1 In general
[thread.mutex.requirements.general]
A mutex object facilitates protection against data races and allows safe
synchronization of data between
execution agents (33.2.5). An execution agent owns a mutex from the time
it successfully calls one of the lock
functions until it calls unlock. Mutexes can be either recursive or
non-recursive, and can grant simultaneous
ownership to one or many execution agents. Both recursive and
non-recursive mutexes are supplied.
33.6.4.2 Mutex types
[thread.mutex.requirements.mutex]
33.6.4.2.1 General
[thread.mutex.requirements.mutex.general]
The mutex types are the standard library types mutex, recursive_mutex,
timed_mutex, recursive_timed_-
mutex, shared_mutex, and shared_timed_mutex. They meet the requirements
set out in 33.6.4.2. In this
description, m denotes an object of a mutex type.
[Note 1 : The mutex types meet the Cpp17Lockable requirements
(33.2.5.3). — end note]
2The mutex types meet Cpp17DefaultConstructible and Cpp17Destructible.
If initialization of an object of a
mutex type fails, an exception of type system_error is thrown. The mutex
types are neither copyable nor
movable.
3The error conditions for error codes, if any, reported by member
functions of the mutex types are as follows:
------ cut here ---------

So she read this far and got tired and decided std::mutex is allowed to
throw. But she should have read the whole thing:

------ cut here ---------
....
Throws: system_error when an exception is required (33.2.2).
------ cut here ---------

and here is what 33.2.2 has to say:
------ cut here ---------
33.2.2
1 [thread]
Exceptions
[thread.req.exception]
Some functions described in this Clause are specified to throw
exceptions of type system_error (19.5.8).
Such exceptions are thrown if any of the function’s error conditions is
detected or a call to an operating system
or other underlying API results in an error that prevents the library
function from meeting its specifications.
Failure to allocate storage is reported as described in 16.4.6.13.
[Example 1 : Consider a function in this Clause that is specified to
throw exceptions of type system_error and specifies
error conditions that include operation_not_permitted for a thread that
does not have the privilege to perform the
operation. Assume that, during the execution of this function, an errno
of EPERM is reported by a POSIX API call
used by the implementation. Since POSIX specifies an errno of EPERM when
“the caller does not have the privilege to
perform the operation”, the implementation maps EPERM to an
error_condition of operation_not_permitted (19.5)
and an exception of type system_error is thrown. — end example]
------ cut here ---------

In other words, lock is allowed to throw *if the underlying OS or API
creates some error condition* -- which a simple POSIX mutex or
pthread_once doesn't -- or "the function's" error condition is defined.
And those error conditions are defined in requirements for lock for
specific mutex types (but Bonita is a writer, she does not need to
read). And for std::mutex:

------- cut here ---------
36.6.4.2.2:
(Class mutex, that is std::mutex)
....
If one thread owns a
mutex object, attempts by another thread to acquire ownership of that
object will fail (for try_lock()) or
block (for lock()) until the owning thread has released ownership with a
call to unlock().
...
If the
implementation can detect the deadlock, a resource_deadlock_would_occur
error condition might be observed.
....
------- cut here ---------
Above is the only error condition that is defined for mutex::lock -- and
it does not apply to Windows or simple POSIX mutices implementation
would use for C++ static initialization (extra cost and complexity, no
benefits and standard non-compliance -- why would anyone used
deadlock-detecting mutex?).

For all other mutex types (not reasonably usable for static
initiazlization), the standard explicitly defines error conditions and
does mentions that they can throw system_error, e.g. for a recursive_mutex:

------- cut here ---------
33.6.4.2.3
Class recursive_mutex
....
If a thread has already acquired the maximum level of ownership for a
recursive_mutex object,
additional calls to try_lock() fail, and additional calls to lock()
throw an exception of type system_error.
------- cut here ---------

Same for timed and shared mutices -- but std::mutex is an exception
(above).

But of course none of the above matters for the subject because C++
mutices don't have to be used (and in fact not used) to implement C++
static variable implementation.

Am 03.10.2023 um 04:24 schrieb Pavel:
> Bonita Montero wrote:
>> Am 02.10.2023 um 01:19 schrieb Pavel:
>>
>>> Nope. The standard never says this specifically about mutex::lock. ...
>>
>> Of course, mutex::lock() may throw a system_error.

> The standard does not say that; ...

https://en.cppreference.com/w/cpp/thread/mutex/lock
"Throws std::system_error when errors occur"