D0690r0 about papers

[jfbastien]

In the enumeration of the four suggested solutions, I feel that at least for the sake of discussion, a fifth solution, described in a sidebar within p0603r0, should be mentioned: change the memory model such that data races aren't undefined behaviour, but rather, that reads of raced data produce indeterminate values, the use of which is undefined behaviour.

There's a mention of std::expected which I think does what you suggest?

p0603r0 says that this is likely to be too radical a change to the memory model, though it would not in general alter program correctness, as aside from these speculative examples programs do not generally read racy data without using the values that have been read.

When I say memory model, I mean the mathematized version. It's not whether it allows something rarely used or even useless, but whether the math can still be made to work out. SG1 has had it as a goal to make the math work out, and I believe there will be a paper in the next mailing which tries to address a super ridiculous usecase which happens to break the current model. Of course we can disagree on whether the math is useful. I see some pretty great upsides in having it.

Adopting such a rule in general would be problematic, due for example to trap values.

Eh, trap values... Not really something I care about 😉

It's too late to change the paper now (mailing deadline passed). I'll see what the committee says and revisit.

[DrPizza]

I realize it's too late to do anything about any of this (much like so much of C++ in general).

I think you mean std::race_or<T>, rather than std::expected, but race_or feels weak for a few reasons.

1. As a template, it's inexpressible in C, and as a practical matter it doesn't feel very desirable to have a model that diverges from C. I mean, I hate C as much as any right-thinking individual does, but I feel that there are some issues where C and C++ need to be in agreement, and this is surely one of them.
2. It still requires the use of std::atomic<T> for values that are never, ever manipulated with atomic operations. In seqlock and ws-queue, it is not merely that we might want to mix and match atomic, ordered operations with non-atomic ones; we do not want atomic, ordered operations at all: explicit fences are used for ordering, and an external locking protocol is used to "simulate" atomicity. Requiring the use of atomic<T> is misleading and carries overhead.
3. It's still divorced from the reality of the machine semantics: byte-wise operations are "atomic" on any reasonable machine; it feels highly desirable to reflect this in whatever model the language defines.

As for the mathematical model, I'm sure it has its place. The model already distinguishes between indeterminate reads and data races, so I'm sure a mathematical model that handled some races as acceptable as long as no indeterminate reads were made could be built.

Moreover, I would posit that a large part of the work on creating and implementing unusual or advanced locking algorithms is done with reference not to any mathematical modelling, but rather to the machine semantics of the platform or platforms of interest. This is, at the least, how our operating systems are built, and it is how things such as seqlocks, futexes, and RCU were invented in the first place--the practical constructs came first, formalization came second.

If the mathematical model does not usefully match the machine semantics that people are using to build synchronization systems, I'm not sure that the mathematical model is entirely useful. It feels quite peculiar to me to say, essentially, "we have this wonderful mathematical model to describe the concurrent semantics of C and C++ programs, and it's entirely irrelevant to many of the most important, most cross-platform C and C++ programs in existence".

One may also hold the view that the entire model is wrong because it is based on locations rather than operations (which is why a number of proposals awkwardly build on std::atomic<T> even when we never want to perform any atomic operations), but this is one of the things that regrettably falls into the "too late to change" category.