I don't think there are any safe ways to use atomic operations from Swift right now. Even the helpers you've written aren't really safe because nothing stops you (or the compiler) from copying the struct around.

@rjmccall, @airspeedswift, do we have a bug tracking the general request already?

Hmm, maybe not in JIRA.

Comment by Krunoslav Zaher (JIRA)

I've wrote unit tests to confirm that the compiler is performing the expected behavior regarding atomic operations.

https://github.com/ReactiveX/RxSwift/blob/master/Tests/RxSwiftTests/AtomicTests.swift

I understand that the compiler doesn't make any guarantees regarding additional copying of the struct, but can anybody provide any reason/rationale why would the Swift compiler decide to perform additional copying of these structs around instead of just passing the pointer to atomic operations?

Comment by Krunoslav Zaher (JIRA)

Is there any timeline when will the Swift compiler allow using atomic operations equivalent to c11 atomics or to deprecated OSAtomic*?

The main thing is that, not knowing that the struct is used as part of an atomic sequence, we reserve the right to rearrange and break up its storage in ways that would defeat atomicity. Forming a pointer to e.g. an Int would require us to reassemble that into the normal ABI, but that guarantee only lasts for the lifetime of that pointer.

Comment by Krunoslav Zaher (JIRA)

@rjmccall Thank you for taking the time to answer my question.

Let me try to rephrase the question.

I'm aware that Swift compiler could in theory decide to rearrange the Int32 storage in ways that would defeat atomicity and only synthesize valid pointer during the mutating method call, but that doesn't really answer my question in full.

I'm trying to find out is anyone aware of any reasons why would the Swift compiler decide to transform code like this.

 var atomic = AtomicPrimitive()  
DispatchQueue.main.async

{     atomic.fetchOr(0)  }

Atomic definition can be found here.

into something that would defy the atomic operations. E.g. I'm aware that if one has a property in a class that has didSet or willSet then the compiler will perform additional copying.

class A {
  var notAtomic: AtomicInt { didSet {  print("Atomic") } }
}

let a = A()

a.notAtomic.fetchOr(8) // <– fail

Comment by Krunoslav Zaher (JIRA)

If the Swift compiler makes absolutely no promises, then what is the rationale for adding reduce(into: method into the public API.

This means that my O(n) algorithms could become O(n^2) algorithms at any moment.

Swift can make a large number of high-level guarantees (e.g. that a stored property will be modified "directly" without introducing a semantic copy) without having to make fine-grained low-level guarantees like pointer equality.

In general, the exclusivity rules on structs prohibit them from being used to implement a meaningful atomic API: you cannot modify `self` in a non-`mutating` method, and it is illegal for other threads to concurrently call any other method while a `mutating` method is underway.

I'm taking this as I'm working on introducing low-level atomic operations.

Atomics require stable memory locations, which are currently achievable by either

• dynamically allocating storage, or

• using ManagedBuffer APIs to carve out inline storage inside a class instance.

Therefore, we are building unsafe atomic constructs that specifically fit these two cases. We expect that move-only (or non-movable) types will eventually replace these with memory-safe alternatives, but it makes sense to still add them so that people can start experimenting with concurrency support in Swift.

Swift-evolution pitch: https://gist.github.com/lorentey/cf8703b5974ebe8f85cfb92a6628880d

Forum thread:
https://forums.swift.org/t/low-level-atomic-operations/34683

Implementation:
#30553

Should we close this since swift-atomics is now available?