Atomic CAS has incorrect semantics when interleaved with non-atomic stores

[GoogleCodeExporter]

What steps will reproduce the problem?
Consider the example:

a = 25

(thread 1) st a, 5    (thread 2) atomic cas a, 25, 0

possible outcomes:

case 0:
(thread 1)
(thread 2)
(thread 2)
a = 0

case 1:
(thread 2)
(thread 2)
(thread 1)
a = 5

case 2:
(thread 2)
(thread 1)
(thread 2)
a = 25

What is the expected output? What do you see instead?

Case 2 is a possible ordering in our implementation, but would not be
possible if the operation was actually performed atomically rather than
using locks. It is very unlikely that a program would ever rely on this
behavior, but it is one more reason to abandon the current locking
implementation and move to an entirely atomic implementation. 

Please use labels and text to provide additional information.

We should consider replacing the current implementation with the upcoming
cstdatomics library.

Original issue reported on code.google.com by gregory....@gatech.edu on 10 Dec 2009 at 5:44

[GoogleCodeExporter]

Fixed in the ptx 2.1 branch.  We now pass atomics to llvm instrinsics.

Original comment by gregory....@gatech.edu on 18 Oct 2010 at 6:49

• Changed state: Fixed