- priority: 5 --> 7
There are race conditions in the implementations of
various op_and_get - like methods and overloaded
operators of the AtomicCounter when based on atomic_t.
These implementations wrongly assume that the sequence
of two atomic operations is again a single atomic
operation.
For example:
int AtomicCounter::operator++(void)
{
atomic_inc(&atomic);
return atomic_read(&atomic);
}
This implementation would allow a scenario where two
concurrent threads increment the counter (atomically);
but only after they both did so, both read the same
value from it (again atomically). This behavior does
not seem intended, is not documented and is very
different form the "fallback" implementation without
atomic_t, which does fulfil the assumed purpose:
int AtomicCounter::operator++(void)
{
int value;
lock.enterMutex\(\); value = ++counter; lock.leaveMutex\(\); return value;
}
The same argument holds for all method implementations
with two consecutive atomic function calls, which are
not protected as a whole unit.
I admit the lack of appropriate atomic_op_and_get
functions for atomic_t. One might urge the kernel
developers into providing some. As long as they are not
available, the atomic_t-based implementation of the
AtomicCounter should be abandoned.