www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - atomic Weapons: The C++ Memory Model and Modern Hardware

reply "Flamaros" <flamaros.xavier gmail.com> writes:
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?
Jul 08 2013
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
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
Jul 08 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jul 8, 2013, at 12:04 PM, Flamaros <flamaros.xavier gmail.com> wrote:

 =

ern-hardware/
=20
 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. =46rom 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.=
Jul 09 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
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.=
Jul 09 2013
prev sibling parent Robert Schadek <realburner gmx.de> writes:
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?

somebody off camera?? Anyway, awesome presentation and awesome presentation style.
Jul 09 2013