atomic operations compared to c++

gzp via Digitalmars-d digitalmars-d at puremagic.com
Wed Jun 14 06:14:28 PDT 2017


> 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.



More information about the Digitalmars-d mailing list