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