It is my understanding that when conforming to Sendable it is safe to use @unchecked if the type is safe to use across tasks using a method the compiler cannot check, e.g. locks. That would mean the following code is valid, does not produce errors or warnings, and the conformance to Sendable is valid too:
final class CustomClass: @unchecked Sendable {
var property: Int {
get {
propertyLock.lock()
defer {
propertyLock.unlock()
}
return _property
}
set {
propertyLock.lock()
defer {
propertyLock.unlock()
}
_property = newValue
}
}
private var _property: Int = 0
private var propertyLock = NSLock()
}
However, if another property is added to this class that isn't Sendable there will be no warnings from the compiler because @unchecked Sendable has been applied to the type.
My first instinct was to add @unchecked to _property, but that doesn't work and I can't find anything referencing a similar syntax that would work for this.
One option I see is to use a wrapper type that uses @unchecked Sendable and contains the locking logic. One example is OSAllocatedUnfairLock, although that's restricted to the latest Apple platforms. Using a custom type for this would also be possible.
Is there a recommended way of writing classes like this to prevent these regressions? Maybe there's an obvious solution I've missed!
Hi @josephduffy, unfortunately writing a truly concurrency safe class is a bit harder than just locking each property. The class you have shared is "safe" to use from multiple threads in that it won't lead to data corruption, but it is not safe in the sense that it is free from race conditions. For example, a simple test where we increment a CustomClass object 10,000 times will fail:
@Test func raceCondition() async {
let object = CustomClass()
await withTaskGroup(of: Void.self) { group in
for _ in 1...10_000 {
group.addTask { object.property += 1 }
}
}
#expect(object.property == 10_000) // ❌
}
This code compiles just fine in Swift 6 language mode, yet the test will not pass. This is because when doing object.property += 1 there are two steps (reading then setting), and each are individually locked. This allows multiple threads to interleave, causing a thread to set a new value in between another thread's read+set.
Locking on a per-property basis is a bit too granular. You should think of instead hiding the data in the class and only exposing more coarse operations that are each locked. For example, your class could have a withProperty method that gives one locked access to an inout integer so that you can do whatever operations you want with it all in a single locked region:
final class CustomClass: @unchecked Sendable {
func withProperty(_ operation: (inout Int) -> Void) {
propertyLock.lock()
defer { propertyLock.unlock() }
operation(&_property)
}
private var _property: Int = 0
private var propertyLock = NSLock()
}
Now accessing the property can only be done in a single locked region, and so now this test will pass:
@Test func raceCondition() async {
let object = CustomClass()
await withTaskGroup(of: Void.self) { group in
for _ in 1...10_000 {
group.addTask { object.withProperty { $0 += 1 } }
}
}
#expect(object.property == 10_000) // ✅
}
Swift 6 also now has a native Mutex type now that exemplifies this pattern (though it's only available on newer platforms). You can put a value in the mutex and the only way to retrieve the value is via a withLock { … } method. But, remember, simply wrapping each field of a class in a Mutex is not enough to make the class free from race conditions.
This makes a good point, but it is also important to point out it has nothing to do with structured concurrency as such.
Structured concurrency can protect you from data races, but not race conditions. The class in the example suffers from a race condition, but if you made it an actor instead, it would still suffer from the race condition.
Swift 6 does nothing to help you with race conditions, and arguably can even make them more likely due to the extra suspension points it may introduce into a codebase.
