This particular problem can be solved more simply by transforming the float to an integer with the right sorting properties and using the atomicMin for integers. See this thread:
I just took a while to study the representation of float and int (i’m not a CS student). I guess when I’m sure the floats I’m trying to compare are positive, there is no need for any processing and the two floats can be compared directly as int. Am I right to say that?
This may be incorrect, suppose two threads both get to the “do loop”, but the smaller one gets to atomicCAS first and the larger gets to atomicCAS, the result thus is not reliable.
change the critical line with
old = atomicCAS((unsigned int*)addr, __float_as_int(assumed), __float_as_int(fminf(value, assumed)));
I just tried the solution + fix proposed by NeilYou (i.e., putting fminf inside atomicCAS) - This does not solve the problem of race condition since the processing of atomicCAS’s arguments are NOT done in an “atomic” way. I witnessed this race condition and saw the errors.