3 ms·
First off, I'd call that barrier-less, which can be more important than lock-less. With the important distinction that it will break on ARM and 'weakly consist
by aray 14y ago
First off, I'd call that barrier-less, which can be more important than lock-less. With the important distinction that it will break on ARM and 'weakly consistent' memory model architectures.
Android's SMP Primer does a really great way of covering this as well, with a lot of race examples, so I recommend checking it out as a compliment: http://developer.android.com/training/articles/smp.html http://developer.android.com/training/articles/smp.html
The author of this article (and probably most readers) will be concerned with x86, which has a "processor-consistent" memory model. What isn't mentioned is that ARM and other architectures have an even weaker ("weakly consistent") memory model. The SMP guide above describes these in detail and how they can be observed (race) here: http://developer.android.com/training/articles/smp.html#datamem_barriers http://developer.android.com/training/articles/smp.html#data...
If you are dealing with low-level problems like this--either in libraries, operating systems, or systems tools and utilities--design for "weakly consistent" memory models, or please leave a huge warning to future developers that it may have subtle and difficult race conditions on those platforms.
- oofabz 14y agoCompareAndSwap implementations use a memory barrier on ARM. That should be sufficient to guarantee correctness.