3 ms·

In the programming I do, this kind of low-level detail hardly ever matters. When I do multi-threading, I only use it in the most simple, stereotypical ways poss

by krylon 5y ago

In the programming I do, this kind of low-level detail hardly ever matters. When I do multi-threading, I only use it in the most simple, stereotypical ways possible, and I use locking very diligently; so far I have run into threading-related problems very, very rarely. But it is very interesting, nevertheless, to get an idea of what is going on under the hood. And given that the subject matter is pretty dry and complex, this article is very well written so someone like me can roughly understand what is going on.

vlovich123 5y ago
This low-level of detail is extremely important to anyone working with atomic variables which can come up in higher-performance code/optimizing, especially since ARM gives you fine-grained knobs for working with atomics than you have on X86 (better performance if you can exploit it, which you usually can). That being said, most people do overestimate the need for atomics in practice.
- krylon 5y ago
  There are situations where it is essential to understand things like memory models etc. Personally, I have not run into a problem that called for atomics. I got by using "conventional" stuff like Mutexes, thread-safe queues (or channels in Go), and the occasional barrier (or WaitGroup, in Go). (I know, goroutines are not the same as threads, but one can easily run into the same problems. So it's best in my experience to treat them like threads when it comes to shared mutable state.)
  - vlovich123 5y ago
    Sure. I expect it comes up infrequently in Go. It comes up a bit more in c++ or Rust because the tooling allows it and people some times over-engineer solutions (still on the rarer side). That being said, at the end of the day all the synchronization primitives you use end up using atomics to actually be implemented. They’re the most fundamental concept everything else is built off of.

by krylon 5y ago

vlovich123 5y ago

This low-level of detail is extremely important to anyone working with atomic variables which can come up in higher-performance code/optimizing, especially since ARM gives you fine-grained knobs for working with atomics than you have on X86 (better performance if you can exploit it, which you usually can). That being said, most people do overestimate the need for atomics in practice.

krylon 5y ago
There are situations where it is essential to understand things like memory models etc. Personally, I have not run into a problem that called for atomics. I got by using "conventional" stuff like Mutexes, thread-safe queues (or channels in Go), and the occasional barrier (or WaitGroup, in Go). (I know, goroutines are not the same as threads, but one can easily run into the same problems. So it's best in my experience to treat them like threads when it comes to shared mutable state.)
- vlovich123 5y ago
  Sure. I expect it comes up infrequently in Go. It comes up a bit more in c++ or Rust because the tooling allows it and people some times over-engineer solutions (still on the rarer side). That being said, at the end of the day all the synchronization primitives you use end up using atomics to actually be implemented. They’re the most fundamental concept everything else is built off of.