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?

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.

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/

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

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

On Aug 5, 2013, at 1:22 PM, zyhong <zyhong@gmail.com> 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?

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.

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.