On 07/02/2017 09:07 AM, Timon Gehr wrote:
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?
Then you atomically load parts of it, the point being that the matter is
present in the type. I must not be understanding the question. -- Andrei
