Something needs to happen with shared, and soon.

[Alex Rønne Petersen]

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

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