Something needs to happen with shared, and soon.

[Alex Rønne Petersen]

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.

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