Hacker News new | past | comments | ask | show | jobs | submit login

> The post is still accurate, but in 2011 C and C++ added atomics, which are a more portable alternative to uses of volatile for atomicity.

Atomics and volatile solve different problems, though. Atomics ensure a read or write completes uninterrupted. Volatile ensures that a read or write is never optimised away.

I think C11 atomics can be optimised away (for example, reading a value twice in a row might result in only a single actual read).

Happy to be corrected, though.




> Atomics and volatile solve different problems, though.

Yep, that's why atomics are only an alternative to uses of volatile _for atomicity_. For the original use case of accessing hardware registers, volatile is still the correct choice.

It is indeed possible for C11 atomics to be optimized, although interestingly, the three major compilers do very little such optimization. This paper [1] lists some optimizations that are implemented in LLVM and some that aren't; it's from 2015 but from some quick testing it seems like not much has changed since.

[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n44...


I have always wondered about that.

If optimizing repeated atomic loads is indeed allowed, waiting for a signal by spinning on an atomic load could loop forever. Yet I have the feeling most people consider such code to be valid. Are they wrong?


Some optimizations are allowed within the rules of the memory model. For example, for an atomic x:

   x=1
   x=2
Can be changed to just x=2. Still forward progress and eventual visibility must be guaranteed.


Acquire loads (and stronger) are required not to loop forever, if they could be observable from another thread. It is mentioned in the linked paper.


While its true that atomic can solve the issue of atomic operations (increment, compare and swap, ...) that volatile doesn't try to solve, it is also required to solve the issue that volatile tried but failed to solve correctly: you have no ordering guaranteed between volatile and non-volatile memory accesses (see problem no.5 of the article).

In that way, atomic complete volatile instead of being orthogonal o it, because it provides the ordering semantic missing in volatile. And it doesn't replace it completely, because as you said, atomic accesses can still be optimized away.

So in most use-cases of volatile, you actually want to declare your variables atomic+volatile along with the correct memory_order on your atomic operations.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: