On 4/1/25 16:26, Michael S wrote:
....

You probably paid attentions that the text is not crystal clear.
It looks like authors of the Standard invent their own terminology not
only when absolutely necessary but sometimes even when there exist established terms for the same things. To their defense, I could say
that in the branch of CS that is related to concurrency and parallelism
very few terms are 100% consensus.

Feel free to propose alternative wording with the same precise meaning.
Keep in mind that these terms were invented to convey a more
precisely-define meaning than existing terms would have provided, so
wording that says "approximately" the same thing would not be an
acceptable replacement.

....

I suspected that the difference between "strong happens before" and
"happens before" is somehow related to implied ordering due to
causality. After reading the text above my feeling changed from
suspicion to strong suspicion. But it is not yet a certainty.

I'm no expert in multi-threaded code, so I don't fully understand the significance of what it says. However, I able to derive the fact that
there is a difference between the two terms only when one evaluation "inter-thread happens before" another evaluation, and the two
evaluations are not synchronized. In other words, the difference is with
regard to what's required for unsynchronized threads.


--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 4/1/25 14:32, James Kuyper wrote:
....

Note that "A is sequenced before D" would be sufficient to ensure that
both "A happens before D" and "A strongly happens before D" are true.
The difference between the two terms only shows up if A is not sequenced before D. In that case, at a minimum you must have "A inter-thread
happens before D", but is not synchronized with D.

For instance A inter-thread happens before D if it is dependency-ordered before D. (6.9.2.1p9). This could happen if A performs a release
operation on an atomic object M , and, in another thread, D performs a consume operation on M and reads the value written by A (6.9.2.1p8).

I got sidetracked by life before I could look into that further, but
I've traced down relevant text in 1.10p7: "An evaluation A that performs
a release operation on an object M synchronizes with an evaluation B
that performs an acquire operation on M and reads a value written by any
side effect in the release sequence headed by A."

Therefore, A "happens before" D, but does not "strongly happen before" D
if A does a release on M, and D does a consume on M, but D does not do
an acquire on M followed by reading a value written by a side effect of
A's release sequence.

--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On Tue, 1 Apr 2025 14:32:54 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wibbled:

"An evaluation A strongly happens before an evaluation D if, either

:

(12.4)— there is an evaluation B such that A strongly happens before B,
and B strongly happens before D.

Looks like a circular definition to me. But regardless, looks like the usual unintelligable nonsense thats no use to anyone except the people who wrote it.

Do you need an explanation of the parts of the above explanation that
use the terms "release" and "consume"? I have little experience with >multi-threaded code - someone else might be able to explain those better
than I can.

I don't particularly care. I generally find standards and RFCs unreadable.
Its often easier to look at code or test with a working example to see what actually happens. Thats the method I used to write my NNTP and NMAP clients amongst many others.


--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

On 01/04/2025 22:10, Michael S wrote:

On Tue, 1 Apr 2025 13:55:43 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

On 4/1/25 00:29, Jakob Bohm wrote:

However treating the standard text as an imperfect description of
traditional compiler techniques used for 2nd. Edition compilers
makes much more sense .

No, that does not. The standard was never intended as a description of
how compilers actually work, it was always intended to be a
description of requirements on how they should work.

It sounds to me like a revisionisms.
Most language standards are intended to codify commonalities of work of existing compilers. That applies to C++98 and mostly, although not completely, to the following C++ standards.
There exist exceptions, for example, Ada83. But they are exceptions.

Most language standards /started/ with a codification of existing tools.
Making a language standard is a lot of effort, and is rarely done
until there is at least one implementation and it has been used for a
while - there's little point spending a lot of time defining a language
that might never be used, or might turn out to be impractical or
inefficient to implement. Initial standards are often books - K&R "The
C Programming Language" and Stroustrup "The C++ Programming Language"
being fine examples. More official standards can come later.

Sometimes there is a "reference implementation" and the documentation
for that becomes, in effect, the standard.

But once the process is in place, it is now the standard that defines
the language, and future implementations are intended to conform to the standard. Implementations can have extensions and extra features, and
those can strongly influence future versions of the standard, but the
standard defines how the language works.

Thus many features that were added to C and C++ after their initial standardisation began as extensions in compilers - especially gcc. But
the standardised features were what the language committees felt were
best for the language going forward - /not/ a codification of existing practice. There are countless examples of new features in language
standards that are clearly inspired by, but noticeably different from, extensions in compilers.



--- MBSE BBS v1.1.1 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)