Something needs to happen with shared, and soon.

[deadalnix]

Le 14/11/2012 00:48, Alex Rønne Petersen a écrit :
> On 14-11-2012 00:43, Alex Rønne Petersen wrote:
>> 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
>>
>
> Scratch that, make it this:
>
> * ubyte, byte
> * ushort, short
> * uint, int
> * ulong, long
> * float, double
> * pointers
> * references
> * function pointers
>
> Slices and delegates can't be loaded/stored atomically because very few
> architectures provide instructions to atomically load/store 16 bytes of
> data (required on 64-bit; 32-bit would be fine since that's just 8
> bytes, but portability is king). This is also why ucent, cent, and real
> are not included in the list.
>

That list sound more reasonable.