• zyhong (7/7) Aug 05 2013 From my understanding, any data type that is less than 32bit
• deadalnix (17/24) Aug 05 2013 You understanding is incorrect.
• qznc (6/9) Aug 05 2013 On x86 every read is an atomic read. The compiler should strip
• zyhong (2/2) Aug 07 2013 thanks for all the answers. they are very helpful. d community is
• John Colvin (5/12) Aug 07 2013 I would highly recommend watching this talk to get a really solid
• Brad Roberts (2/6) Aug 05 2013 For most platforms, writing anything other than a register word size is ...
• Sean Kelly (22/23) Aug 05 2013 char, int, etc) is atomic and there is no need to use atomicLoad/Store =

"zyhong" <zyhong gmail.com> writes:

 From my understanding, any data type that is less than 32bit 
(bool, char, int, etc) is atomic and there is no need to use 
atomicLoad/Store and read/write the data to be thread safe. In 
std.parallelism, I saw it use atomicLoad/Store for any shared 
data. Could anyone clarify if it is really necessary to 
atomicLoad/Store to read/write data that datatype is bool, int, 
byte, etc?

"deadalnix" <deadalnix gmail.com> writes:

On Monday, 5 August 2013 at 20:22:37 UTC, zyhong wrote:
 From my understanding, any data type that is less than 32bit 
 (bool, char, int, etc) is atomic and there is no need to use 
 atomicLoad/Store and read/write the data to be thread safe. In 
 std.parallelism, I saw it use atomicLoad/Store for any shared 
 data. Could anyone clarify if it is really necessary to 
 atomicLoad/Store to read/write data that datatype is bool, int, 
 byte, etc?

You understanding is incorrect.

First, non atomic read.write don't guarantee any ordering, which
necessary when it come to sharing on a multiprocessor machine
(almost all machines nowadays).

Second, the fact that the CPU is capable of atomic read.write do
not mean that the compiler will issue an atomic read/write. The
compiler can :
   - load/store larger chunk (ie can load 32bits, modify 8bits of
it and store back 32bits when you update an byte).
   - eliminate load/store (as they do not change the single
threaded semantic).
   - reorder load/stores (same as above).
   - load/store byte by byte (unlikely, but legal).

Additionally, guarantee are hardware dependent. So if some of
these may not be useful on X86, which have a very strong memory
model, not using atomic makes it more difficult to port D.

"qznc" <qznc web.de> writes:

On Tuesday, 6 August 2013 at 06:01:55 UTC, deadalnix wrote:
 Additionally, guarantee are hardware dependent. So if some of
 these may not be useful on X86, which have a very strong memory
 model, not using atomic makes it more difficult to port D.

On x86 every read is an atomic read. The compiler should strip
away all overhead from the library constructs. The writes are not
strong enough.

I can recommand Sutters talk about atomics. It is 3h long, though.

http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-modern-hardware/

"zyhong" <zyhong gmail.com> writes:

thanks for all the answers. they are very helpful. d community is 
just too good.

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Monday, 5 August 2013 at 20:22:37 UTC, zyhong wrote:
 From my understanding, any data type that is less than 32bit 
 (bool, char, int, etc) is atomic and there is no need to use 
 atomicLoad/Store and read/write the data to be thread safe. In 
 std.parallelism, I saw it use atomicLoad/Store for any shared 
 data. Could anyone clarify if it is really necessary to 
 atomicLoad/Store to read/write data that datatype is bool, int, 
 byte, etc?

I would highly recommend watching this talk to get a really solid 
understanding of the topic:

http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2

http://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-2-of-2

Brad Roberts <braddr puremagic.com> writes:

On 8/5/13 1:22 PM, zyhong wrote:
  From my understanding, any data type that is less than 32bit (bool, char,
int, etc) is atomic and
 there is no need to use atomicLoad/Store and read/write the data to be thread
safe. In
 std.parallelism, I saw it use atomicLoad/Store for any shared data. Could
anyone clarify if it is
 really necessary to atomicLoad/Store to read/write data that datatype is bool,
int, byte, etc?

For most platforms, writing anything other than a register word size is NOT
atomic.

Sean Kelly <sean invisibleduck.org> writes:

On Aug 5, 2013, at 1:22 PM, zyhong <zyhong gmail.com> wrote:

 =46rom my understanding, any data type that is less than 32bit (bool, =

char, int, etc) is atomic and there is no need to use atomicLoad/Store =
and read/write the data to be thread safe. In std.parallelism, I saw it =
use atomicLoad/Store for any shared data. Could anyone clarify if it is =
really necessary to atomicLoad/Store to read/write data that datatype is =
bool, int, byte, etc?

If you are modifying something that is size_t.sizeof bytes and that data =
is properly aligned, it will be modified atomically on x86 assuming the =
compiler ever actually issues a MOV instruction.  Note that there are a =
lot of ifs in the previous sentence.  If you modify a bool, for example, =
it's possible that it could be done via a bus-width read-modify-write =
operation that includes the values of adjoining variables.  Or the =
compiler may determine that, according to the as-if rule, it doesn't =
have to issue the write at all, or maybe it thinks it can rearrange =
things so the write occurs before or after other nearby operations.

If you're super concerned about efficiency and are certain that order of =
operations doesn't matter, use atomicStore!msync.raw.  That will at =
least ensure that the write actually occurs and does so in an atomic =
manner.  But in general, I'd stick with the fully fenced atomic write, =
and really, I'd avoid atomic operations altogether and use a mutex or =
something similar instead.  Atomics are almost never worth the trouble =
that they incur in terns of added algorithm complexity.