skaller wrote:
Ah .. ok I think I finally see. Thanks! The code ensures
well definedness by checking the establishment of the
required invariant and dynamically chosing whether or not
to do the access on that basis .. and the optimisation
above defeats that by lifting the access out of the
conditional.
In the single threaded case the lift works because it
relies on sequential access, which is the only possibility
for a single thread.
But this is clearly not a similar case. There is a clear
read-modify-write cycle taking place (-= operator), and you describe the
problem in a way that a decrement with the value of zero is allowed.
The problem domain that is atomic read-modify-write is not the same as a
atomic assignment, which is the basis of the original issue. More over
the original issue was a write access to variable where none was
described in the code for that given circumstance.
Along the lines of my my first post to this thread, if you want atomic
read-modify-write then you are doing to have to create your
atomic_int_dec(int *intptr) function, or atomic_int_sub(int *intptr, int
value) which makes uses of IA32 CPU lock prefix instructions. But for
many other platforms (almost all RISC) you are going to have to obtain a
mutex lock then perform a 'load from memory to register', 'substract
value', 'store to memory from register'.
Darryl
