On 07/12/2016 03:51 PM, Kagamin wrote:
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.
I'm not sure what you're saying here. Should unsafe reading and writing
of shared types simply be allowed and have the common syntax (as it is
now), and the programmer should make sure that things are set up correctly?
That's a reasonable stance, but it's not the one that D takes towards
shared when `shared int x; ++x` is deprecated.
The problem is when an unshared postblit is called on the shared data.
I understand that. The programmer who writes the cast would have to work
around it. I agree that it's rather ugly. Maybe a function can be
written that does an unsafe copy and then calls the shared postblit.
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.
So a "raw load" is just a non-atomic load after all? When I asked
earlier you wrote "raw atomic load" in your reply, so I assumed it was
some kind of atomic load.
Supporting non-atomic load in atomicLoad would be weird, wouldn't it? It
would be opposite of what it says on the label.
Would the point be that it calls the shared postblit (unlike casting
shared away and then copying)? As mentioned above, I'd hope that a
function that does that can be written.
I didn't manage to find out what the "5th kind of synchronization" is.
If it's important for this discussion, please elaborate.
