On 07/11/2016 01:52 AM, Alex Parrill wrote:
Atomic loading and storing, from what I understand, is usually limited
to about a word on most architectures. I don't think it would be good to
implicitly define assignment and referencing as atomic operations, since
it would be limited. IMO concurrent access is better off being explicit
anyway.
Simply disallow reading and writing shared then, forcing something more
explicit like atomicLoad/atomicStore?
That would be better than the current state, but it would make shared
even more unwieldy.
Generating atomic operations would break less code, and feels like the
obvious thing to me. It would be kinda explicit: shared being involved
gives it away. Also, with other forms of ensuring thread safety, you
have to cast shared away anyway, so atomic reading/writing wouldn't be
applied there.
I don't think there is an issue with converting unshared reference types
to shared (ex. ref T -> ref shared(T) or T* -> shared(T)*); worst you
get is some extra synchronization.
shared(T)* is not shared itself, so that's fine, yeah.
I think I've approached this from the wrong angle. Implicit conversions
are not the problem. Reading/writing is. Copying a shared value to
another shared location is unsafe, too, if not done atomically.
