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