Re: C aggregate passing (Rust kernel policy)

Ralf Jung
2025-02-28T08:08:05Z

Hi,

>> The reason? The standards people wanted to describe the memory model
>> not at a "this is what the program does" level, but at the "this is
>> the type system and the syntactic rules" level. So the RCU accesses
>> had to be defined in terms of the type system, but the actual language
>> rules for the RCU accesses are about how the data is then used after
>> the load.
>
> If your point is that this should be phrased in terms of atomic
> accesses instead of accesses to atomic objects, then I absolutely
> agree with you. This is something I tried to get fixed, but it
> is difficult. The concurrency work mostly happens in WG21
> and not WG14.
>
> But still, the fundamental definition of the model is in terms
> of accesses and when those become visible to other threads, and
> not in terms of syntax and types.

The underlying C++ memory model is already fully defined in terms of "this is
what the program does", and it works in terms of atomic accesses, not atomic
objects. The atomic objects are a thin layer that the C++ type system puts on
top, and it can be ignored -- that's how we do it in Rust.

(From a different email)
> It sounds you want to see the semantics strengthened in case
> of a data race from there being UB to having either the old
> or new value being visible to another thread, where at some
> point this could change but needs to be consistent for a
> single access as expressed in the source code.

This would definitely impact optimizations of purely sequential code. Maybe that
is a price worth paying, but one of the goals of the C++ model was that if you
don't use threads, you shouldn't pay for them. Disallowing rematerialization in
entirely sequential code (just one of the likely many consequences of making
data races not UB) contradicts that goal. Given that even in highly concurrent
programs, most accesses are entirely sequential, it doesn't seem unreasonable to
say that the exceptional case needs to be marked in the program (especially if
you have a type system which helps ensure that you don't forget to do so).

Kind regards,
Ralf