[Second Review] SE-0410: Atomics

[Karl]

@lorentey

However, it isn't quite clear to me that this has been previously covered. SE-0302 talks a lot about "the safety of passing data between concurrency domains", but I can't remember if I saw a clear definition of precisely what that means.

Do we consider it safe to pass borrows of AtomicCountBy2 between concurrency domains, even if doing so can lead to (high-level) race conditions?

The construct does avoid undefined behavior, which is already a quite strong guarantee -- is it okay to consider that our official litmus test, then?

IMO, yes.

We can never fully protect against misuses of an API, and some things are just inherently complex and their use requires great care. We try to design and document APIs such that they guide developers to correct usage, but we can't make anything entirely foolproof.

String, for instance, attempts to provide an easy-to-use interface for Unicode text. It is still possible to mess it up. For instance, a recent discussion surfaced the following example from the Vapor framework:

@benlings

let pathComponents = request.url.path
            .split(separator: "/")
            .map(String.init)

Canonically-equivalent-to-the-grapheme-cluster-"/" is not the correct way to process a path string, which should be split on the ASCII character U+002F SOLIDUS.

Floating-point numbers are another example: they often look like decimal numbers, but they don't work that way. They're generally fine if you're computing geometry to render on-screen, but you wouldn't want pension fund calculations to be subject to floating-point inaccuracies.

In this case, AtomicCountBy2 fundamentally has misunderstood atomics: despite the object model inferring that atomicity is a property of memory locations, in fact it is a property of operations. Fundamentally, atomic operations do not compose -- the combination of 2 atomic operations is not, itself, atomic. If the developer of AtomicCountBy2 was trying to make their increment() method atomic, they used the wrong API calls for that.

@lorentey

borrowing func increment() -> (oldValue: Int, newValue: Int) {
    let old = _value.increment().oldValue
    let new = _value.increment().newValue
    return (old, new)
}  

Once you think of atomicity at the level of operations, it is clear why this happened, and what the solution is. "Atomic" comes from the Greek Atomos, meaning indivisible. If you an operation can be split in to constituent operations, clearly it cannot be atomic.

I don't think it's possible for Sendable to protect against high-level bugs like this, just as we can't in general protect against people using the wrong String view or the wrong numeric type/operation.

It may be possible, however, to introduce some kind of macro which validates that APIs which wrap atomics truly only perform a single atomic operation along each path.