Something needs to happen with shared, and soon.

[deadalnix]

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.