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

Timon Gehr via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 2 06:07:15 PDT 2017


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?


More information about the Digitalmars-d mailing list