Low-Level Atomic Operations

[lorentey (Karoy Lorentey)]

@Chris_Lattner3

I think the name should still capture that it is reference-y. Something like UnsafeAtomicPointer or UnsafeAtomicReference or UnsafePointerToAtomic seems like it would make more room for the ownership-enabled future where we could have a non-reference version of the same thing.

Leaving room for the non-copiable variant is not a concern here -- the "proper" atomic generic will be called Atomic<Value>.

UnsafeAtomicPointer<Value> is uncomfortably close to UnsafeMutablePointer<Pointee>, to the point of confusion. UnsafePointerToAtomic<Value> lends itself to a general naming scheme, so let's go with that one.

struct UnsafePointerToAtomic<Value>
struct UnsafePointerToAtomicLazyReference<Instance>
struct UnsafePointerToUnfairLock

@Chris_Lattner3

• This naming issue is even more pressing if you intend to introduce a pattern that is followed by higher level types like mutexes etc. It is practical to use an extra layer of pointer indirection in the immediate future, but we really need to be set up to be able to eliminate this in the future.

Again, this is a non-issue; the eventual move-only variants won't have any of these naming warts.

moveonly struct Atomic<Value>
moveonly struct AtomicLazyReference<Instance>
moveonly struct UnfairLock

@Chris_Lattner3

Perhaps this is just a writing thing but I'd recommend the " The Atomics Module" section include a few examples using optionals and IUOs with the pointer type. If this isn't supported, it should be.

I'll try adding more examples. Optionals are explicitly supported.

Supporting implicitly unwrapped optionals with UnsafePointerToAtomic<Value> isn't feasible. We aren't modeling IUOs in the standard library any more, and UnsafePointerToAtomic<Foo!> is not supported as syntax.

Modeling IUOs through a separate type would be possible, of course:

struct UnsafePointerToAtomicImplicitlyUnwrappedOptional<Wrapped: NullableAtomic> {
  func isNil(ordering: AtomicLoadOrdering) -> Bool
  func load(ordering: AtomicLoadOrdering) -> Wrapped // traps on nil
  ...
}

However, I feel that low-level atomics are tricky enough to use correctly without having to deal with arbitrary implicit behavior layered on top of them. I don't think having to spell out the ! (or having to manually implement such a type) is going to be a hardship -- so I don't think such a construct belongs in the stdlib.

@Chris_Lattner3

For example, your AtomicCounter example has a separately allocated atomic, which is unnecessarily wasteful. It would be great if it could be written as something like this instead:
[...]

UnsafeAtomic<Int>.wrappingIncrement(address: &_value, by: 1, ordering: .relaxed)

Agreed. But the language provides no (reliable) way to retrieve the memory location of a class instance variable -- the above code has undefined behavior. I previously explored this area in Exposing the Memory Locations of Class Instance Variables.

The implicit inout-to-pointer conversion is not appropriate for atomics, and I feel it's harmful to the language in general. The problem is that there is no way to disallow this conversion from occurring through a temporary variable. (I attempted to spell this out in Interaction with implicit pointer conversions.) The fact that it mostly works in practice is a huge problem, because we have no reasonable suggestion to replace it for people who absolutely do need to do such things. (Including the stdlib, sometimes.)

The only currently supported way to define "inline" storage for atomics is through ManagedBuffer.withUnsafeMutablePointerToHeader and MemoryLayout.offset(of:). This is decidedly not pretty, even in the lucky case where the Header is a single atomic value.