On 14/06/2017 1:48 PM, Russel Winder via Digitalmars-d wrote:
> On Wed, 2017-06-14 at 13:27 +0100, rikki cattermole via Digitalmars-d
> wrote:
>>
> […]
>> Yes. A N.G. post will be forgotten about quickly, but an issue in
>> the
>> bug tracker can send you updates as things progress.
> 
> OK. Feel free to sign me up for the issue.

If an issue is created, you can add yourself pretty easily (cc field).

>> At the end of the day, that module grew organically, it just needs a
>> bit
>> of planning put into it for the future that's all.
> 
> Which module?

core.atomic

> I am fairly sure it isn't, but why is this needed if you use a parallelism oriented approach to the architecture and design? Sorry to repeat but whilst there are circumstances where this stuff is needed (operating systems), most other applications should be written without the need for locks, mutexes, fences, memory model, etc. any need for that stuff should be covered in the frameworks used.
>
> We need to be careful not to bring 1960s views of threads into 2010 programming. Sometimes they are needed, usually they are not.

Atomic is not meant to replace the higher level abstraction things (neither in c++ nor in any other language). They are meant to implement new higher lever abstraction layers as a library instead of as a language feature.
As new parallel algorithms are discovered, they can be (not so) "easily" added to the languages through libs. How would you implement a lock-free list? Or a lock-free multiple producer, single consumer queue? It's good to have send/receive mechanism in a parallel world, but in my opinion the framework should be a library and not the language itself. And to easy the writing of such libraries some good, reliable building blocks are required (mutex, atomic, fence, etc.).
You are right these features are not meant to be used too much, but required to build more general parallel, containers, schedulers, algorithms etc.

Note: Why do I keep mentioning C++11 with respect to atomic?
Because some experts spent a lot of time to find a good stable API for these things.

Actually I've just found an isue from 2015 (still in NEW state):
https://issues.dlang.org/show_bug.cgi?id=15007
I've updated and linked this forum.

On Wednesday, 14 June 2017 at 12:15:49 UTC, Russel Winder wrote:
> On Wed, 2017-06-14 at 12:28 +0100, rikki cattermole via Digitalmars-d wrote:
>> > [...]
>
> Step back a moment. C++ and Java are trying to stop programmers using these features, in favour of using higher level abstractions. In C++ and Java such features as above are often required to implement the higher level abstraction but so as to allow other programmers not to have to use them.
>
> [...]

Especially since D has officially support for inline assembly. All these low-level constructs are better handled directly at the machine code level as their semantic varies significantly between architectures.

Hi,

On Tuesday, 13 June 2017 at 06:12:46 UTC, gzp wrote:
> the docs are quite minimal

That's true. In fact, this applies not only to atomic intrinsics, but all of `shared`. We need to sit down and properly specify things at some point. Andrei has been trying to get an initiative going to do just that recently.

> There is no consume in D.

There is indeed no equivalent to memory_order_consume. Note, however, that consume is about to be deprecated in C/C++, as it turned out to be more or less unimplementable in its current form (at least while still being useful). Introducing the notion of source-level dependencies into a language that otherwise operates with as-if semantics on an abstract machine is a tricky business.

> But what about compare_exchange (CAS) ? […] Does it mean,
> it is the strongest sequaential all the time

Yes, core.atomic.cas() is always seq_cst for the time being (we should fix this).

> Another issue is the fence. In D there is no memoryordering for fence, only the strongest one exists. Is it intentional?

No; it is just a questionable design decision/unnecessary limitation which can easily be remedied by adding an optional parameter.

 — David

On Wednesday, 14 June 2017 at 12:48:14 UTC, Russel Winder wrote:
> On Wed, 2017-06-14 at 10:40 +0000, gzp via Digitalmars-d wrote:
>> […]
>> cas
>> in all api I've seen on a failed swap, the current value is
>> retrieved
>> (in c/c++ there are intrinsic for them)
>
> This appears to be in core.atomic.

There is a misunderstanding here. cas() is in core.atomic, but it returns true/false rather than the read value. However, this is just fine for virtually all algorithms. In fact, the respective <atomic> functions in C++11 also return a boolean result.

>> exchange
>> no api for it and not implementable without spinning
>> (in c/c++ there are intrinsic for them)
>
>
>> atomicFence
>> No memory ordering is considered in the API
>> Even tough it falls back to the strongest/slowest one for the
>> current implementation it should be part of the API.
>
> Appears to be in core.atomic.

Where exactly would that be? There is no unconditional swap/xchg in core.atomic, and atomicFence() indeed only supports sequentially consistent semantics.

 — David

On Wed, Jun 14, 2017 at 10:51 AM David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 14 June 2017 at 12:48:14 UTC, Russel Winder wrote:
> > On Wed, 2017-06-14 at 10:40 +0000, gzp via Digitalmars-d wrote:
> >> […]
> >> cas
> >> in all api I've seen on a failed swap, the current value is
> >> retrieved
> >> (in c/c++ there are intrinsic for them)
> >
> > This appears to be in core.atomic.
>
> There is a misunderstanding here. cas() is in core.atomic, but it returns true/false rather than the read value. However, this is just fine for virtually all algorithms. In fact, the respective <atomic> functions in C++11 also return a boolean result.
>
> >> exchange
> >> no api for it and not implementable without spinning
> >> (in c/c++ there are intrinsic for them)
> >
> >
> >> atomicFence
> >> No memory ordering is considered in the API
> >> Even tough it falls back to the strongest/slowest one for the
> >> current implementation it should be part of the API.
> >
> > Appears to be in core.atomic.
>
> Where exactly would that be? There is no unconditional swap/xchg in core.atomic, and atomicFence() indeed only supports sequentially consistent semantics.
>
>   — David
>

FWIW, I fixed this. https://github.com/dlang/druntime/pull/2745