On Tuesday, 12 July 2016 at 12:47:05 UTC, ag0aep6g wrote:
In contrast, unsafe reading/writing of shared data that looks like just another assignment is similarly problematic and harder to spot.
It's strange if you want to expose a bare volatile variable to the rest of the world and expect the world to cope with concurrency on every access.
If reading/writing shared directly would be disallowed completely (always have to use core.atomic or cast), then shared postblits wouldn't make sense anymore, I guess.
The problem is when an unshared postblit is called on the shared data.
Correct me if I'm wrong: Currently, the compiler generates a non-atomic load for reading shared data. In particular, it doesn't generate a raw atomic load. And you say you can't do a raw atomic load with core.atomic.atomicLoad.
I say non-atomic load is not supported by atomicLoad. 5th kind of synchronization will help here.
