I just filed issue #45, asking UnsafeAtomic, ManagedAtomic and friends to be marked Sendable, reflecting that they are safe to transfer across concurrency domains.
I plan to do this the following way:
#if compiler(>=5.5) && canImport(_Concurrency)
extension UnsafeAtomic: @unchecked Sendable where Value: Sendable {}
extension ManagedAtomic: @unchecked Sendable where Value: Sendable {}
extension UnsafeAtomicLazyReference: @unchecked Sendable where Instance: Sendable {}
extension ManagedAtomicLazyReference: @unchecked Sendable where Instance: Sendable {}
#endif
Is this a good idea?
Is there a reason not to do this?
What exactly would break if atomic values weren'tSendable?
I assume that in most use cases, atomics values are used as mere components of other types (typically classes), whose sendability would need to be explicitly marked anyway -- nobody should be relying on Sendable inference for concurrent data structures.
On the other hand, I can imagine people passing around, say, a ManagedAtomic<Int> to implement a concurrent counter -- it seems reasonable that this should be implicitly Sendable:
struct Foobar {
var counter: ManagedAtomic<Int>
var value: String = ""
}
I think the managed versions are clearly Sendable.
The Unsafe versions are not as clear, because nothing in them controls the lifetime of the memory location they refer to. I’m not concerned about the semantics of using the type but about the requirement to manage the lifetime of the memory location.
Of course, there is no doubt that they can be used correctly and productively in multithread/multiactor situation, but the construct that is marked Sendable should perhaps be at a higher level?
I'm not sure what you would do with Atomics if they weren't Sendable. where Value: Sendable seems like an adequate safeguard. I do think both Unsafe and Managed should be @unchecked Sendable.
If someone deliberately uses atomics and explicitly specifies too weak of an ordering, then I think they get the race condition that they asked for.
Amusingly, pointer sendability means that UnsafeAtomic implicitly became unconditionally Sendable in Swift 5.5.
This means that constraining its conformance to where Value == Sendable in a new release would technically be a source-breaking change, which can in theory only be done in a new major release.
Hm, that depends on the details of how that's done, but I would be surprised if it involved a different module name -- I expect it'd be done by putting a special version of libswift_Concurrency.dylib inside app bundles that gets loaded if there is no such library in the OS (i.e., like old stdlib binaries that ship in apps that deploy back to before the stdlib was part of the OS, but made more complicated because the implementations need to be different). [Note though that I know nothing, and I'm surprised at least once every day. ]
$Sendable doesn't test for the right thing, sadly -- it's testing a compiler feature, while what we need to ensure is that we are using a stdlib that defines Sendable. (For macOS, Xcode 13 ships with the Swift 5.5 compiler but the 5.4 stdlib, so its compiler is aware of this stuff, but its stdlib isn't.)
]