core.atomics and handling of backward MemoryOrders

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Sat Jul 4 02:12:58 PDT 2015


On 4 July 2015 at 10:39, rsw0x via Digitalmars-d <
digitalmars-d at 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" <
>> digitalmars-d at puremagic.com> wrote:
>>
>>> [...]
>>>>
>>> __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.
>>
>> [...]
>>
>
> 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.
>


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150704/9e97c817/attachment-0001.html>


More information about the Digitalmars-d mailing list