On 29/11/2017 13:16, Stefan Hajnoczi wrote: > While the atomics documentation is good, atomics themselves have been a > source of difficult bugs. > > They should be used as little as possible and only where they can be > encapsulated in a composable abstraction (i.e. don't expect users of > your abstraction to understand atomics). > > Why? They are damn hard to use. None of us is capable of using them > without introducing difficult bugs. > > There is also a temptation to rely on implicit effects of other code > (e.g. when you know there is a barrier in another function) for best > performance. That's a bad property for code to have because it becomes > hard to change safely.
I agree. atomics.txt should be augmented with examples of well-known idioms/patterns and a big red sign "if this is not what you're doing, don't do it". However, I'll note that in the end atomics are not very different from very small critical sections. If anything, atomics have the advantage that you have to think more about acquire/release semantics. So it's in general a matter of "being as clever as you need, but not more than that" (and IMO util/async.c and util/qemu-coroutine-lock.c do need all the cleverness they can muster, but it should stop there). Thanks, Paolo
signature.asc
Description: OpenPGP digital signature
