Why do "const inout" and "const inout shared" exist?

[Timon Gehr via Digitalmars-d]

On 02.07.2017 15:29, Andrei Alexandrescu wrote:
> 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

In general, depending on the hardware memory model and the language 
memory model, data transfer from one thread to another requires 
cooperation from both parties. We don't want the thread that has the 
unshared data to need to participate in such a cooperation.