On 10/2/2023 8:30 PM, Pavel wrote:
> 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.
>>

[... snip std ...]
> 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:
[... snip std ...]

Well, shit. It almost has to be Bonita misreading and/or not reading the
std. My first thoughts was that she got all of her limited info from:

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

and just made up some rules on the fly, and sticks with them... Even
though she knows they are not correct. Humm...

Am 03.10.2023 um 04:28 schrieb Pavel:

> What is a "non-trivial" type and where did you find it initialized in
> the code by Frederick?

A trivial type is a type that can be trivially construted and trivially
copied. His vector<int> isn't trivial in that sense.
His global vector<int> doesn't need to be thread-safe initialized since
it is global and it is initialized before main() or before the shared
object initialitation routine returns. But if it would be static local
the same he did manually with call_conce would be done by the compiler
and the runtime; so that's effort for nothing.

On 10/2/23 22:28, Pavel wrote:
> Bonita Montero wrote:
....
>> 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?

"Scalar types, trivial class types (11.2), arrays of such types and
cv-qualified versions of these types are collectively called trivial
types." (6.8p9). The term "trivial types" is italicized, an ISO
convention indicating that this sentence constitutes the official
definition of that term. A non-trivial type is any type that doesn't
qualify as a trivial type.

An easy way to test whether a type is trivial is to look at
std::is_trivial<T> (20.15.4.3p4).

On 10/3/2023 8:28 PM, James Kuyper wrote:
> On 10/2/23 22:28, Pavel wrote:
>> Bonita Montero wrote:
> ...
>>> 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?
>
> "Scalar types, trivial class types (11.2), arrays of such types and
> cv-qualified versions of these types are collectively called trivial
> types." (6.8p9). The term "trivial types" is italicized, an ISO
> convention indicating that this sentence constitutes the official
> definition of that term. A non-trivial type is any type that doesn't
> qualify as a trivial type.
>
> An easy way to test whether a type is trivial is to look at
> std::is_trivial<T> (20.15.4.3p4).
>

poor old std::is_pod<T>

;^)

Am 04.10.2023 um 05:28 schrieb James Kuyper:

> An easy way to test whether a type is trivial is to look at
> std::is_trivial<T> (20.15.4.3p4).

Or look at the runtime for the checks if_trivial depends on.

Bonita Montero wrote:
> 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"
>
>
ccpreference.com is not the standard. Where it disagrees with the
standard, the standard prevails.

Am 05.10.2023 um 04:03 schrieb Pavel:
> Bonita Montero wrote:
>> 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"
>>
>>
> ccpreference.com is not the standard. Where it disagrees with the
> standard, the standard prevails.

Idiot

On 10/4/23 10:40 PM, Bonita Montero wrote:
> Am 05.10.2023 um 04:03 schrieb Pavel:
>> Bonita Montero wrote:
>>> 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"
>>>
>>>
>> ccpreference.com is not the standard. Where it disagrees with the
>> standard, the standard prevails.
>
> Idiot
>

Yes you are. And you just admitted you don't understand what a
"Standard" is.

On 10/5/2023 4:56 AM, Richard Damon wrote:
> On 10/4/23 10:40 PM, Bonita Montero wrote:
>> Am 05.10.2023 um 04:03 schrieb Pavel:
>>> Bonita Montero wrote:
>>>> 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"
>>>>
>>>>
>>> ccpreference.com is not the standard. Where it disagrees with the
>>> standard, the standard prevails.
>>
>> Idiot
>>
>
> Yes you are. And you just admitted you don't understand what a
> "Standard" is.
>
>

Bonita is special. ;^)

Bonita Montero wrote:
> Am 05.10.2023 um 04:03 schrieb Pavel:
>> Bonita Montero wrote:
>>> 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"
>>>
>>>
>> ccpreference.com is not the standard. Where it disagrees with the
>> standard, the standard prevails.
>
> Idiot
>
I know you are

Am 05.10.2023 um 04:03 schrieb Pavel:

> ccpreference.com is not the standard. Where it disagrees with the
> standard, the standard prevails.

You're right, the standard even goes one step futher than cppreference:

* "The 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 expression m.lock() is well-formed and has the following
semantics: ... Throws: _system_error_ when an exception is
required (33.2.2)."

So en.cppreference.com missed that initialization of a mutex
also might throw system_error.

On 9/29/2023 1:44 PM, Kaz Kylheku wrote:
> On 2023-09-29, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 29.09.2023 um 22:09 schrieb Chris M. Thomasson:
>>
>>> Huh? The code you write always has race conditions? Huh?
>>
>> Theres a random factor which determines who acquires a mutex first.
>> So this is a true race condition. So a race condtition can be totally
>> acceptable inside a mutex, but not outside a mutes with the code that
>> uses the mutex.
>
> The concept of a race condition is broad; it spans beyond software.
>
> A race condition is a situation in which the system's behavior being
> correct or incorrect depends on the incidental order of events between
> unrelated event streams.
>
> The system design assumes, for its correctness, that a certain event X
> happens before Y, but this is not ensured and sometimes doesn't happen
> because X and Y come from different event sources/streams which are not
> synchronized.
>
> In software, if we have divided the execution of a program into multiple
> scheduling contexts, like threads, it's possible that the program will
> arrive at its result via different execution orders. If for all
> execution orders, the result is correct, then there is no race
> condition.
>
> Your mutex-based program may exhibit different execution orders.
>
> There is no race condition unless some of the execution orders produce
> an incorrect result.
>
> Unfortunately, we cannot speak about correctness without referring to
> the specification of the individual program. Correctness is not
> absolute.
>
> Suppose we have a specification "write a program that prints all the
> integers in the range 1 to 10, on a separate linee". We can have the
> program launch ten threads, give each of the threads one of those
> integers as an argument. Each thread prints the argument and
> terminates.
>
> If we see an output like, this it is correct:
>
> 7
> 3
> 1
> 6
> 9
> 8
> 4
> 5
> 2
> 10
>
> (Assume that we never see bad character interleaving; the I/O library
> takes care of that.)
>
> Now suppose we change the requirements that the integers have to be
> presented in increasing order.
>
> Then the same program is no longer correct, and we can identify it as
> having race conditions.
>
> It starts the 1-10 threads in order, but they don't issue their output
> in that order.
>
> The program hasn't change at all, only the specification of what is
> correct, and that causes the program to have a race condition.
>
> We agree that there are always perturbations in execution order
> regardless of how correcntess is defined: the program does what it does.
>
> A perturbation in execution order isn't a race; only when it
> makes the program incorrect w.r.t it specification.
>

Well, that is pretty much it.

Bonita Montero wrote:
> Am 05.10.2023 um 04:03 schrieb Pavel:
>
>> ccpreference.com is not the standard. Where it disagrees with the
>> standard, the standard prevails.
>
> You're right, the standard even goes one step futher than cppreference:
>
> * "The 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 expression m.lock() is well-formed and has the following
>   semantics: ... Throws: _system_error_ when an exception is
>   required (33.2.2)."
Did you read what your cited? "when an exception is required (33.2.2)"
for std::mutex, exception is not required unless the mutex is deadlock
detecting (and deadlock-detecting mutex is not appropriate to use for
static initialization). But it is good you at least starting to read.
>
> So en.cppreference.com missed that initialization of a mutex
> also might throw system_error.