Something needs to happen with shared, and soon.

[Alex Rønne Petersen]

On 14-11-2012 01:09, deadalnix wrote:
> Le 14/11/2012 00:43, Alex Rønne Petersen a écrit :
>> On 14-11-2012 00:38, Andrei Alexandrescu wrote:
>>> On 11/13/12 3:28 PM, Alex Rønne Petersen wrote:
>>>> On 13-11-2012 23:33, Andrei Alexandrescu wrote:
>>>>> shared int x;
>>>>> ...
>>>>> x = 4;
>>>>>
>>>>> You'll need to use x.store(4) instead.
>>>>
>>>> Is that meant to be an atomic store, or just a regular, but explicit,
>>>> store?
>>>
>>> Atomic and sequentially consistent.
>>>
>>>
>>> Andrei
>>
>> OK, but then we have the problem I presented in the OP: This only works
>> for certain types, on certain architectures, for certain processors, ...
>>
>> So, we could limit shared load/store to only work on certain types and
>> require all architectures that D compilers target to provide those.
>> *But* this means that shared on any non-primitive types becomes
>> essentially useless and will in 99% of cases just be casted away. On the
>> other hand, if we make it implementation-defined, people end up writing
>> highly unportable code. So, (unless anyone can come up with better
>> alternatives), I think guaranteeing atomic load/store for a certain set
>> of types is the most sensible way forward.
>>
>> FWIW, these are the types and type categories I'd expect shared
>> load/store to work on, on any architecture:
>>
>> * ubyte, byte
>> * ushort, short
>> * uint, int
>> * ulong, long
>> * float, double
>> * pointers
>> * slices
>> * references
>> * function pointers
>> * delegates
>>
>
> I wouldn't expected it to work for delegates, long, ulong, double and
> slice on every arch. If it does work, that is awesome, and add to my
> determination that this is the thing to do.

8-byte atomic loads/stores is doable on all major architectures.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org