CustomDebugStringConvertible AtomicBox about cwlutils

[mattgallagher]

Code of the form extension X: Y where X.A: B is called a "conditional conformance". They are not possible in Swift 4.0 but are a planned feature of Swift 4.1 (branch exists on github and should be part of the Xcode builds in a month or two). You could do it dynamically in the meantime – implement the extension for all AtomicBox<T> but check if internalValue is CustomDebugStringConvertible and take different action.

However, accessing internalValue without the mutex simply isn't threadsafe – even with a non-class type – since the AtomicBox turns it into a class type. You simply cannot safely access the internalValue without a mutex like this.

You claim that you're seeing deadlocks? The only reason this would happen on debugDescription is if your type T is triggering recursion back into the AtomicBox mutex during debugDescription. The correct way to handle this problem is to work out why this recursion is occurring and eliminate it through a redesign of the mutex protected interface to avoid re-entrancy.

[t0rst]

You claim that you're seeing deadlocks?

No, normal operation designed so that there are no deadlocks. I'm just anticipating that if I'm debugging and I happen to cause debugDescription to be evaluated while the AtomicBox mutex is locked higher up the stack, then that's my debugging session screwbar'd, hence I need debugDescription to bypass the mutex in order to be safely deliver insight during debugging. (As well as needing it for logging.)

Maybe I've misunderstood, but I thought let valueType = someOtherValueType was thread safe? Assigning class type reference let thingRef = anInstanceOfThingClass has to be thread safe, otherwise ARC's promises would be broken (Mike Ash on Swift Weak Refs - see "This means that loading a weak reference and destroying a weakly-referenced object can be done without acquiring locks.", which shines a light on reference counting integrity). And behind the scenes value types are reference types with COW for mutation (except when they are pointer values), so I'd assumed the reference counting promise would be kept in the same way as for classes. Hence, let t = internalValue splits off a copy of the boxed value at that point in time. (Assuming a similar mechanism is used as for weak references, then the behind-the-scenes reference to internalValue is incremented atomically and is thread-safe.)

[mattgallagher]

I thought let valueType = someOtherValueType was thread safe?

Sometimes yes, sometimes no. If someOtherValueType is inside a reference type and that reference type is shared, then it is not safe.

There's a distinction between:

• plain values with no references to them
• a reference (a plain address)
• the underlying object storage
• the count of references referring to the underlying storage

Plain values with no reference to them are always threadsafe. And references counts are always threadsafe – this is what Mike Ash's article is about.

But data stored inside a reference type (object storage) is never threadsafe (unless you use a mutex or the storage cannot be mutated from any thread).

And references themselves are a little complicated since they are always read safe for concurrent access but not write safe – and the specific level of safety here has changed over time, as discussed in this pull request:

apple/swift#1454

Pay attention to McCall's comment "In general, Swift does not guarantee correctness in the presence of read/write, write/write, or anything/destroy data races on a variable". The only concurrent access that is safe is "read/read".

This code: let valueType = someOtherValueType may include read access to a reference. But you cannot access the contents of that reference if it might be mutated from another thread. The contents must either be strictly read-only or you need to use a mutex. The general case must assume that a mutex is required.

As for COW objects... multiple COW wrapper structs on multiple threads might share the same underlying storage (since shared storage become strictly read-only) but you cannot reference a single COW wrapper struct from multiple threads.

Bring it back to AtomicBox... remember that AtomicBox is itself a reference – if you're using it at all, it's probably a shared reference. This means that if you try to read the contents of the AtomicBox, you're accessing "underlying object storage" which is, as I stated above, "never threadsafe (unless you use a mutex or the storage cannot be mutated from any thread)".