8 ms·

Question to anyone more knowledgeable about swift, why does it recommend against using atomics? It makes a joke about thread sanitizer, but what actual steps do

Question to anyone more knowledgeable about swift, why does it recommend against using atomics? It makes a joke about thread sanitizer, but what actual steps do you have to go through to use atomics in swift safely?

favorited 6y ago
The same as in any language, really. The problem is that some developers assume "atomics == thread safe, so I'll make an easy way to mark things as 'atomic' and I won't have to worry about it." That's why the standard advice on iOS and macOS was to mark properties as explicitly `nonatomic` – because it was almost never the right tool for the job.
- querez 6y ago
  Sorry for my ignorance, but: why isn't atomic == threadsafe?
  - andrewl-hn 6y ago
    Just a guess. Individual variables may be atomic, but that doesn't guarantee that a series of operations over one or several of them is thread safe. Thus it's likely that a developer using atomics still makes mistakes, and yet they get a false sence of safety.
  - wool_gather 6y ago
    This is in the context of properties in ObjC, which will synthesize accessor methods for the developer. If the property is marked `atomic` (which is also the default), the getter and setter will share a mutex. The mutex makes reads and writes effectively "atomic" -- gets and sets on different threads will never interrupt one another. But that's all you get. And the catch is that there's usually more you need to do to guarantee thread safety for a particular operation. For example, `@property (atomic) NSMutableArray *array;` has no guarantees about appending or removing the array's _contents_. For another example `@property (atomic) NSUInteger count;` is a mildly subtle trap, because a statement like `self.count += 1;` is _not atomic_. It's an atomic read, an increment, and an atomic write. You need another synchronization mechanism to make the whole update threadsafe.
saagarjha 6y ago
Atomic are low-level concurrency primitives; often a mutex is all you’ll ever need and they’re much easier to reason about.
pornel 6y ago
They're surprisingly difficult to use correctly, especially if you're trying to build something clever like lock-free data structures. Atomic access can use relaxed memory ordering, meaning that values don't actually change immediately for all threads. There are subtle rules about what changes the hardware and the optimizer can delay and reorder. It's like playing chess with threads. There's also a common pitfall that x86 hardware has more consistent and forgiving behavior than the spec for atomic operations. Broken atomic code may appear to work fine on x86, but fall apart on ARM.
- my123 6y ago
  Not all ARM CPUs even, there's a wide range between those using the relaxed memory model in the spec, some server CPUs having TSO (roughly matching x86) and others having sequential consistency (NVIDIA in-house CPUs).
Sharlin 6y ago
If you’re prepared and willing to learn much more about atomic operations than you ever thought you would, there’s no substitute to Herb Sutter’s classic talk ”atomic<> Weapons” from C++ And Beyond 2012 [1]. [1] https://www.youtube.com/watch?v=A8eCGOqgvH4 https://www.youtube.com/watch?v=A8eCGOqgvH4

favorited 6y ago

The same as in any language, really. The problem is that some developers assume "atomics == thread safe, so I'll make an easy way to mark things as 'atomic' and I won't have to worry about it." That's why the standard advice on iOS and macOS was to mark properties as explicitly `nonatomic` – because it was almost never the right tool for the job.

querez 6y ago
Sorry for my ignorance, but: why isn't atomic == threadsafe?
- andrewl-hn 6y ago
  Just a guess. Individual variables may be atomic, but that doesn't guarantee that a series of operations over one or several of them is thread safe. Thus it's likely that a developer using atomics still makes mistakes, and yet they get a false sence of safety.
- wool_gather 6y ago
  This is in the context of properties in ObjC, which will synthesize accessor methods for the developer. If the property is marked `atomic` (which is also the default), the getter and setter will share a mutex. The mutex makes reads and writes effectively "atomic" -- gets and sets on different threads will never interrupt one another. But that's all you get. And the catch is that there's usually more you need to do to guarantee thread safety for a particular operation. For example, `@property (atomic) NSMutableArray *array;` has no guarantees about appending or removing the array's _contents_. For another example `@property (atomic) NSUInteger count;` is a mildly subtle trap, because a statement like `self.count += 1;` is _not atomic_. It's an atomic read, an increment, and an atomic write. You need another synchronization mechanism to make the whole update threadsafe.

saagarjha 6y ago

Atomic are low-level concurrency primitives; often a mutex is all you’ll ever need and they’re much easier to reason about.

pornel 6y ago

They're surprisingly difficult to use correctly, especially if you're trying to build something clever like lock-free data structures. Atomic access can use relaxed memory ordering, meaning that values don't actually change immediately for all threads. There are subtle rules about what changes the hardware and the optimizer can delay and reorder. It's like playing chess with threads. There's also a common pitfall that x86 hardware has more consistent and forgiving behavior than the spec for atomic operations. Broken atomic code may appear to work fine on x86, but fall apart on ARM.

my123 6y ago
Not all ARM CPUs even, there's a wide range between those using the relaxed memory model in the spec, some server CPUs having TSO (roughly matching x86) and others having sequential consistency (NVIDIA in-house CPUs).

Sharlin 6y ago

If you’re prepared and willing to learn much more about atomic operations than you ever thought you would, there’s no substitute to Herb Sutter’s classic talk ”atomic<> Weapons” from C++ And Beyond 2012 [1]. [1] https://www.youtube.com/watch?v=A8eCGOqgvH4 https://www.youtube.com/watch?v=A8eCGOqgvH4