Realtime threads with Swift

[ksluder (Kyle Sluder)]

@John_McCall

No. If the retain doesn't happen before the release, then they can race, and the retain can lose. It's just fundamentally not a salvageable situation.

I think we’re referring to two separate problems. This sounds like a description of resurrection, which can happen even if all atomic accesses are well-ordered. I’m asking about decoherence, where two threads disagree on the temporal ordering of changes to a memory location despite exclusively accessing that location through atomic operations.

@John_McCall

Also, spin locks are required to synchronize — to establish well-ordering under happens before — or else they're not really locks in any sense and cannot be used in lock-like patterns where they protect access to other memory.

I can see where you’re coming from, but if the program correctly orders all of its own atomic memory accesses and still manages to corrupt an object’s refcount because a runtime it has no insight into chose to use a relaxed memory ordering, isn’t that the runtime’s fault?