On Jul 8, 2013, at 12:04 PM, Flamaros <flamaros.xav...@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.
