3 ms·

If you're mutating the same atomic across 100 threads you're gonna have a bad time. Atomic doesn't mean fast. Hell, that might even be slower than using a mutex

• jeffbee 2y ago
  Indeed, the article is quite misleading by supposing that atomic variables are magic at the hardware level. On some hardware yes, on others no. As an example the original AWS Graviton is vanilla armv8-a without atomics, so atomic concepts in languages are simulated with retry loops having unbounded latency. Your thread that wants to increment an atomic may be blocked literally forever if there are enough contenders for that cache line. Library mutex implementations are usually hybrids with limited atomic spinlocks, with pauses or sleeps, then fallbacks to heavyweight synchronization with fairness features such as futex. On certain Intel hardware we also have lightweight userspace notification when a given address has been written. That can be used for adaptive wakeup on atomic values but it is "lightweight" relative to futex, since it still requires a rdtsc and still amounts to an efficient spinloop. On Intel Atom CPUs you can do this with up to 4 threads for free, but 100 threads will still be a mess.
• jay-barronville 2y ago
  > Hell, that might even be slower than using a mutex? It depends, of course, on how the mutex is implemented, but yes, this is the reality a lot of times. The thing about atomics is that they can appear simple to naïve eyes, but the semantics are very difficult to get right (especially if you want your code to be portable across architectures).
• helpfulContrib 2y ago
  [dead]