atomic operations compared to c++

Russel Winder via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 14 05:15:49 PDT 2017


On Wed, 2017-06-14 at 12:28 +0100, rikki cattermole via Digitalmars-d
wrote:
> On 14/06/2017 11:40 AM, gzp wrote:
> > After digging into it the source for me it seems as D is lacking a 
> > "standardized" atomic library. It has some basic concepts, but far 
> > behind the c++ standards.
> > I don't know if there are any RFC-s in this topic but it requires a
> > lot 
> > of work. Just to mention some by my first experience:
> > 
> > cas
> > in all api I've seen on a failed swap, the current value is
> > retrieved
> > (in c/c++ there are intrinsic for them)
> > 
> > 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.
> > 
> > If D wants be be a real system programming language (ex a
> > replacement 
> > for c++) please address these issues. I'm not an expert on the
> > subject, 
> > but D seems to be in a c++11 stage where compiler/memory barriers
> > and 
> > atomic had to be implemented differently for each platform and the 
> > programmer could only hope that compiler won't f*ck up everything
> > during 
> > optimization.

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.

That D can do the high level parallel and concurrent programming using
a more actor style model, i.e. processes and channels, or data
parallelism, tasks on a threadpool, that C++11 didn't have but C++17
has (I believe), potentially means there is no reason to slavishly
follow other languages in providing features that are not needed.

So what is it that requires D to have CAS, exchange, and atomicFence?
This proposal to introduce them needs driving by showing what C++ can
do at the application level that D cannot, rather than being tick box
driven via a list of types.

C++ and Java have formal memory models because people use a lot of
shared memory multithreading. If you use actor/dataflow/data
parallelism at the application level then it is entirely feasible to
get away without a formal memory model as long as the
actor/dataflow/data parallelism frameworks can be constructed without
one. It is, of course, easier to do this if there is a memory model. So
the first port of call has to be "does D have a formal memory model"
rather than dopes it have CAS, exchange, and fences.

Oh, and if you can avoid fences you must.

Remember, locks, semaphores, mutexes, barriers, and fences are all
designed to stop parallelism, they are designed to slow things down.
They are needed for implementing operating system, but unless your
application is an operating system in some sort of disguise, you really
don't want them in your code.

Investigation may discover that D is missing some of these features,
but there needs to be a reason to have them other than "other languages
have them".  

> > I don't know if D compiler is aware of the fences and won't move
> > out/in 
> > instructions from guarded areas.
> > 
> > Thanks: gzp
> 
> Please create an issue here: issues.dlang.org for druntime atomic
> support.
> Clearly the requirements that we have been working under are not up
> to 
> your expectations (or needs).

Is an issue the right vehicle for investigating the need for these?

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20170614/28ec16eb/attachment.sig>


More information about the Digitalmars-d mailing list