x86[-64]:Remove ‘volatile’ from atomic_t
Linus Torvalds [Wed, 6 Dec 2006 22:42:57 +0000 (14:42 -0800)]
Any code that relies on the volatile would be a bug waiting to happen
anyway.

Don’t encourage people to think that putting ‘volatile’ on data
structures somehow fixes problems. We should always use proper locking
(and other serialization) techniques.

Thanks for the pointer to the “volatile considered harmful” discussion. That addition to the documentation looks very worthwhile.

Many other architectures still do have volatile on their atomic_t typedef. Is this because Linus hasn’t gotten around to fixing those yet, or is there some reason that volatile is more appropriate on other architectures?

A final note about the atomicity of reading and writing ints — your post about __attribute__((packed)) shows how this assumption sometimes doesn’t hold. If someone put an atomic_t inside a packed structure, then all bets are off, right? That would surely be a bug, but perhaps atomic_t should have an __attribute__((aligned))?

You say that using atomic_t makes your variable volatile. This is not true: on mainstream architectures such as i386 and x86_64, has

typedef struct { int counter; } atomic_t;

with no volatile in sight. In any case, the recent thread on LKML about adding documentation about “volatile considered harmful” to the kernel shows that in almost all cases, you don’t want your variable to be declared volatile anyway. When reviewing code, I can be pretty sure that an explicit “volatile” declaration is either unnecessary or marking a bug.

As far as assuming that reading and writing an int are atomic, I think that assumption is pretty deeply ingrained in the Linux implementation. Just about every lock-free algorithm that uses memory barriers is implicitly assuming that it will never read a half-written value. And certainly every implementation of atomic_read() for all Linux architectures boils down to a simple read of an int.

So no, I don’t think that “abstracted atomicity” is a reason to use atomic_t.

(BTW, It is legitimate to use atomic_t and atomic_set() if you are also using atomic bit ops)

The only reason atomic_set() and atomic_read() are useless here is because you’re assuming that reading or writing an int is always an atomic operation. This is probably true of the architectures you care about, but can you really say that this will be true for all architectures? Using atomic_t explicitly declares the need for the assignment to be atomic, where that abstraction may then do whatever is necessary on every architecture.

The other side effect of using atomic_t is that your variable becomes volatile, which may have an important effect on the compiled code.

So you gain abstracted atomicity and volatileness. Are you still willing to say that this isn’t worthwhile? Or is it just that this need is outside of what you consider “the vast majority of the time”?

PS – I hope you’ll excuse my pedantry for the sake of argument