Optimization of conditional access to globals: thread-unsafe?

[Darryl Miles]

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