On 02.07.2017 14:41, Andrei Alexandrescu wrote:
On 07/01/2017 07:55 PM, Timon Gehr wrote:
On 02.07.2017 01:08, Andrei Alexandrescu wrote:
Vaguely related question: should "const" convert implicitly to "const
shared"? The intuition is that the latter offers even less guarantees
than the former so it's the more general type. See
http://erdani.com/conversions3.svg.
That would be nice because we have "const shared" as the unique root
of the qualifier hierarchy.
This means that there can be aliasing between an unqualified reference
and a const shared reference. Therefore, you can have code that
mutates unshared data while another thread is reading it.
What should the semantics of this be?
The only potential issue is that it could restrict code operating on
unshared data because it needs to play nice in some way to allow
consistent data to be read by another thread.
Well const shared exists already with the semantics of "you can't modify
this and you must load it atomically to look at it". The question is
whether the conversion from const to const shared can be allowed. -- Andrei
If the data is not written atomically, how can it be loaded atomically?