Brian LewisOct 5, 2024
Matt Massicotte

Great answer from @mbrandonw about the challenges of locking properties. Definitely a pattern I’m seeing a lot lately.

https://forums.swift.org/t/preventing-regressions-when-conforming-to-sendable-with-unchecked/62137/4

Preventing regressions when conforming to `Sendable` with `@unchecked`

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 ...

Swift Forums
Oct 5, 2024 at 4:08pmMona for iPhone
Show threadRob NapierOct 5, 2024

@mattiem @mbrandonw I keep seeing people reach for an @ Locked property wrapper and I have to (gently) slap their hands. It’s very rarely what you want, and so rare that your don’t need a property wrapper.

But Swift concurrency also makes it so hard to create good atomic “snapshots” of state that you do want, without forcing Apple code you don’t control to support async. And that’s something we need better answers to. AsyncSequence is the obvious thing to reach for but bites you every time.