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

Is D and DMD aware of those kind of issues with atomic?

Am Mon, 08 Jul 2013 21:04:01 +0200
schrieb "Flamaros" <flamaros.xavier@gmail.com>:

> http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-modern-hardware/
> 
> Is D and DMD aware of those kind of issues with atomic?

I haven't looked into the talk, but I can say this: D offers atomic operations like loads, stores, fences and CAS. They are the lowest level you can go and the responsibility to be informed about the caveats lies with you as the programmer. I recently wrote a mostly lock free circular buffer and on the D IRC channel there were a few helpful people who made me aware of how multi-core CPUs and caches work. Fortunately on x86 architectures at least, atomic operations are pretty sane and fast.

Other threading options in D are classical mutexes and conditions or thread communication through message passing, which is at the highest level and really hard to mess up. :)

-- 
Marco

On Jul 8, 2013, at 12:04 PM, Flamaros <flamaros.xavier@gmail.com> wrote:

> http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-modern-hardware/
> 
> Is D and DMD aware of those kind of issues with atomic?

I think more thought needs to be given to how the compiler recognizes and treats atomic operations in D.  In D1, we had "volatile" as a means of telling the compiler that it shouldn't optimize code according to certain rules, but this has been deprecated in D2.  And while DMD doesn't optimize inside or across asm blocks, other compilers may.  "shared" is somewhat helpful here, but even then I'm not entirely certain that a compiler like GDC will not do something unsafe with code that's intended to be atomic.

From an API perspective, D has a label roughly akin to "atomic" in "shared", and even supports relaxed atomics via core.atomic.  If it matters, the original API in core.atomic (atomicLoad and atomicStore) is based on a design by Alexander Terekhov, who influenced both the Boost and C++0x design.  I think I even participated in the C++0x memory model discussion back in the beginning if you're inclined to dig through the archives, and aside from Andrei and Walter the community has a few other folks with a good knowledge of low-level concurrency.  Either way, I think D's support for concurrency is less extensive than on C++0x (no futures, for example) but is reasonably solid and with some nice overlays, like std.concurrency.  Life is also a bit easier for us because D doesn't support as many architectures as C++, so we don't currently need as much code behind things like core.atomic to make everything work.  But I'm confident that the existing APIs could extend to weak architectures without alteration.

In short, we're aware of the issues and have a good foundation, but more work needs to be done.

On Jul 8, 2013, at 5:05 PM, Marco Leise <Marco.Leise@gmx.de> wrote:

> Fortunately on x86
> architectures at least, atomic operations are pretty sane and
> fast.

The x86 memory model is sufficiently strict that, by and large, simple concurrent interactions actually work without any memory barriers at all.  I've never been able to decide whether this is a good or a bad thing however.

On 07/08/2013 09:04 PM, Flamaros wrote:
> http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-modern-hardware/
>
>
> Is D and DMD aware of those kind of issues with atomic?
OT: How does he change slides? I can't see a clicker nor a sign for
somebody off camera?? Anyway, awesome
presentation and awesome presentation style.