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
a...@lycus.org
http://lycus.org
