digitalmars.D - core.atomics and handling of backward MemoryOrders
- Iain Buclaw (17/17) Jul 03 2015 Hi,
- rsw0x (3/20) Jul 03 2015 IIRC these flat out error on LDC, I meant to submit a bug report
- Iain Buclaw via Digitalmars-d (35/56) Jul 04 2015 __sync_* builtins to the new (more compatible with how core.atomics is
- rsw0x (5/19) Jul 04 2015 This is how it's currently implemented in C++ as of C++14,
- Iain Buclaw via Digitalmars-d (11/38) Jul 04 2015 Yes, that is correct. I think closely matching the behaviour of C++14 i...
- Iain Buclaw via Digitalmars-d (10/44) Jul 04 2015 digitalmars-d@puremagic.com> wrote:
- Martin Nowak (3/6) Jul 08 2015 It makes sense to disallow them, but I wonder why they are
- Iain Buclaw via Digitalmars-d (6/12) Jul 08 2015 They *aren't* allowed in C++.
- Martin Nowak (4/6) Jul 08 2015 I was under the impression that I died them once with no effect
Hi, I'm currently re-writing core.atomics for GDC to switch from the old GCC __sync_* builtins to the new (more compatible with how core.atomics is supposed to function) __atomic_* builtins. https://github.com/D-Programming-GDC/GDC/pull/111 One thing I've noticed in my reading of this, is that the following are accepted as valid, but makes no sense. --- atomicStore!(MemoryOrder.acq)(var, val); var = atomicLoad!(MemoryOrder.rel)(val); --- I'd like to suggest that it should be considered completely valid for both cases to throw a compilation error (using static assert). However I'd like the core druntime team to be on board with this. Regards Iain.
Jul 03 2015
On Friday, 3 July 2015 at 17:51:17 UTC, Iain Buclaw wrote:Hi, I'm currently re-writing core.atomics for GDC to switch from the old GCC __sync_* builtins to the new (more compatible with how core.atomics is supposed to function) __atomic_* builtins. https://github.com/D-Programming-GDC/GDC/pull/111 One thing I've noticed in my reading of this, is that the following are accepted as valid, but makes no sense. --- atomicStore!(MemoryOrder.acq)(var, val); var = atomicLoad!(MemoryOrder.rel)(val); --- I'd like to suggest that it should be considered completely valid for both cases to throw a compilation error (using static assert). However I'd like the core druntime team to be on board with this. Regards Iain.IIRC these flat out error on LDC, I meant to submit a bug report but I forgot until I read this.
Jul 03 2015
On 4 Jul 2015 00:50, "rsw0x via Digitalmars-d" <digitalmars-d puremagic.com> wrote:On Friday, 3 July 2015 at 17:51:17 UTC, Iain Buclaw wrote:__sync_* builtins to the new (more compatible with how core.atomics is supposed to function) __atomic_* builtins.Hi, I'm currently re-writing core.atomics for GDC to switch from the old GCCaccepted as valid, but makes no sense.https://github.com/D-Programming-GDC/GDC/pull/111 One thing I've noticed in my reading of this, is that the following areboth cases to throw a compilation error (using static assert). However I'd like the core druntime team to be on board with this.--- atomicStore!(MemoryOrder.acq)(var, val); var = atomicLoad!(MemoryOrder.rel)(val); --- I'd like to suggest that it should be considered completely valid forforgot until I read this. Good to know, as I understand it, there's currently the following behaviour in dmd runtime. atomicLoad!(Memoryorder.seq) -> issues a lock+exchange. atomicLoad!(Memoryorder.acq) -> lock-free (only because of x86 guarantees). atomicLoad!(Memoryorder.rel) -> issues a lock+exchange. atomicLoad!(Memoryorder.raw) -> no lock. atomicStore!(Memoryorder.seq) -> issues a lock+exchange. atomicStore!(Memoryorder.acq) -> issues a lock+exchange. atomicStore!(Memoryorder.rel) -> lock-free (only because of x86 guarantees). atomicStore!(Memoryorder.raw) -> no lock. Is it fine to consider the following (for optimisation purposes, of course :) atomicLoad!(Memoryorder.seq) -> Can be lock-free (only because of x86 guarantees), but guaranteed to do the right thing otherwise. atomicLoad!(Memoryorder.acq) -> Can be lock-free (only because of x86 guarantees), but guaranteed to do the right thing otherwise. atomicLoad!(Memoryorder.rel) -> static assert. atomicLoad!(Memoryorder.raw) -> no lock. atomicStore!(Memoryorder.seq) -> Can be lock-free (only because of x86 guarantees), but guaranteed to do the right thing otherwise. atomicStore!(Memoryorder.acq) -> static assert. atomicStore!(Memoryorder.rel) -> Can be lock-free (only because of x86 guarantees), but guaranteed to do the right thing otherwise. atomicStore!(Memoryorder.raw) -> no lock. Iain.Regards Iain.IIRC these flat out error on LDC, I meant to submit a bug report but I
Jul 04 2015
On Saturday, 4 July 2015 at 07:16:09 UTC, Iain Buclaw wrote:On 4 Jul 2015 00:50, "rsw0x via Digitalmars-d" <digitalmars-d puremagic.com> wrote:This is how it's currently implemented in C++ as of C++14, correct? acquire semantics on a write and release semantics on a load make no sense, so this probably should be changed.__sync_* builtins to the new (more compatible with how core.atomics is supposed to function) __atomic_* builtins.[...]accepted as valid, but makes no sense.[...]both cases to throw a compilation error (using static assert). However I'd like the core druntime team to be on board with this.[...][...]forgot until I read this. [...]
Jul 04 2015
On 4 July 2015 at 10:39, rsw0x via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Saturday, 4 July 2015 at 07:16:09 UTC, Iain Buclaw wrote:Yes, that is correct. I think closely matching the behaviour of C++14 is the safe option given that this module shares a lot in common with std::atomic. std::atomic::atomic_compare_exchange_strong -> core.atomic.cas std::atomic::memory_order -> core.atomic.MemoryOrder std::atomic::atomic_load -> core.atomic.atomicLoad std::atomic::atomic_store -> core.atomic.atomicStore std::atomic::atomic_thread_fence -> core.atomic.atomicFence Iain.On 4 Jul 2015 00:50, "rsw0x via Digitalmars-d" < digitalmars-d puremagic.com> wrote:This is how it's currently implemented in C++ as of C++14, correct? acquire semantics on a write and release semantics on a load make no sense, so this probably should be changed.[...]supposed to function) __atomic_* builtins.__sync_* builtins to the new (more compatible with how core.atomics is[...]accepted as valid, but makes no sense.[...]I'd like the core druntime team to be on board with this.both cases to throw a compilation error (using static assert). However[...]forgot until I read this. [...]
Jul 04 2015
On 4 Jul 2015 11:12, "Iain Buclaw" <ibuclaw gdcproject.org> wrote:On 4 July 2015 at 10:39, rsw0x via Digitalmars-d <digitalmars-d puremagic.com> wrote:digitalmars-d puremagic.com> wrote:On Saturday, 4 July 2015 at 07:16:09 UTC, Iain Buclaw wrote:On 4 Jul 2015 00:50, "rsw0x via Digitalmars-d" <supposed to function) __atomic_* builtins.__sync_* builtins to the new (more compatible with how core.atomics is[...]I'd like the core druntime team to be on board with this.accepted as valid, but makes no sense.[...]both cases to throw a compilation error (using static assert). However[...]sense, so this probably should be changed.This is how it's currently implemented in C++ as of C++14, correct? acquire semantics on a write and release semantics on a load make no[...]forgot until I read this. [...]Yes, that is correct. I think closely matching the behaviour of C++14 isthe safe option given that this module shares a lot in common with std::atomic.std::atomic::atomic_compare_exchange_strong -> core.atomic.cas std::atomic::memory_order -> core.atomic.MemoryOrder std::atomic::atomic_load -> core.atomic.atomicLoad std::atomic::atomic_store -> core.atomic.atomicStore std::atomic::atomic_thread_fence -> core.atomic.atomicFence Iain.OK, I've added static asserts to my PR. Iain.
Jul 04 2015
On Saturday, 4 July 2015 at 10:47:17 UTC, Iain Buclaw wrote:It makes sense to disallow them, but I wonder why they are allowed in C++.I'd like the core druntime team to be on board with this.both cases to throw a compilation error (using static assert). However
Jul 08 2015
On 8 July 2015 at 10:46, Martin Nowak via Digitalmars-d < digitalmars-d puremagic.com> wrote:On Saturday, 4 July 2015 at 10:47:17 UTC, Iain Buclaw wrote:They *aren't* allowed in C++. GCC will give you a compiler warning if you attempt it, and stdc++ should invoke a cxx_assert on it's use. Iainboth cases to throw a compilation error (using static assert). HoweverIt makes sense to disallow them, but I wonder why they are allowed in C++.I'd like the core druntime team to be on board with this.
Jul 08 2015
On Wednesday, 8 July 2015 at 13:58:24 UTC, Iain Buclaw wrote:GCC will give you a compiler warning if you attempt it, and stdc++ should invoke a cxx_assert on it's use.I was under the impression that I died them once with no effect (might have been clang). In any case, feel free to go forward with a static assert check.
Jul 08 2015