Nick Piggin writes: > Why are people making these undocumented and just plain false > assumptions about atomic_t?
Well, it has only been false since December 2006. Prior to that atomics *were* volatile on all platforms. > If they're using lockless code (ie. > which they must be if using atomics), then they actually need to be > thinking much harder about memory ordering issues. Indeed. I believe that most uses of atomic_read other than in polling loops or debug printk statements are actually racy. In some cases the race doesn't seem to matter, but I'm sure there are cases where it does. > If that is too > much for them, then they can just use locks. Why use locks when you can just sprinkle magic fix-the-races dust (aka atomic_t) over your code? :) :) > > Precisely. And volatility is a key property of "atomic". Let's please > > not throw it away. > > It isn't, though (at least not since i386 and x86-64 don't have it). Conceptually it is, because atomic_t is specifically for variables which are liable to be modified by other CPUs, and volatile _means_ "liable to be changed by mechanisms outside the knowledge of the compiler". > _Adding_ it is trivial, and can be done any time. Throwing it away > (ie. making the API weaker) is _hard_. So let's not add it without Well, in one sense it's not that hard - Linus did it just 8 months ago in commit f9e9dcb3. :) > really good reasons. It most definitely results in worse code > generation in practice. 0.0008% increase in kernel text size on powerpc according to my measurement. :) > I don't know why people would assume volatile of atomics. AFAIK, most By making something an atomic_t you're saying "other CPUs are going to be modifying this, so treat it specially". It's reasonable to assume that special treatment extends to reading and setting it. > of the documentation is pretty clear that all the atomic stuff can be > reordered etc. except for those that modify and return a value. Volatility isn't primarily about reordering (though as Linus says it does restrict reordering to some extent). Paul. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
