4 ms·
Volatile is never the answer if your question is about locking.
by jjnoakes 10y ago
Volatile is never the answer if your question is about locking.
- jhallenworld 10y agoWell you are right in the sense that volatile should not be used in place of locking primitives, and that even when implementing locking primitives, it's not enough (you need memory barriers, probably in an assembly language snippet market as __volatile__). That being said, if the lock variable itself if marked as volatile, the compiler should take the hint based on its simple definition "value could change at any time", and not try to combine in with unrelated read-modify-write accesses. Otherwise why wouldn't you want the compiler to speed up or compress bitfields?
- jjnoakes 10y agoNot only is it not enough, using volatile for locking primitives is a bad idea and should not be done. It slows down the program with no benefits. A correct multi-thrraded program is correct with or without volatile, and so removing volatile can only speed things up and should be done.