On Tue, Oct 15, 2013 at 10:18:15AM +0800, Peter Chen wrote:
> So, the lessons for this topic are:
>
> - If one atomic variable's operation only includes one instruction like
> atomic_read and atomic_set, it is not meaningful for using atomic
> operation, we can just use bool instead of it.
The lesson here is that these are 100% equivalent as far as safety from
races is concerned:
a = atomic_read(&v); a = v->counter;
atomic_set(&v, b); v->counter = b;
and in general, whenever atomic_read() gets used it's almost certainly
a sign of a bug.
Consider this (similar has been submitted):
a = atomic_read(&v);
if (a != 0)
a += 1;
atomic_set(&v, a);
and people have thought that somehow this is magically safe from races
because they're using atomic_t, and somehow that saves the universe.
The above is in fact no safer than:
a = *v;
if (a != 0)
a += 1;
*v = a;
The only thing that using atomic_* does is add a false sense of security
and a level of obfuscation to catch the unwary reviewer.
The reason is quite simple: a single access read in itself is atomic.
Either it has read the value, or it hasn't. A single access store is
itself atomic. Either the data has been written, or it hasn't. The
issue is _always_ what you do around it.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
