3 ms·
Perhaps you might appreciate that there is a wide spectrum of problems that might require parallelism, from dramatically simple enterprise apps to "massively co
by balakk 13y ago
Perhaps you might appreciate that there is a wide spectrum of problems that might require parallelism, from dramatically simple enterprise apps to "massively concurrent quoting/trading engines".
This advice is written for the 90% of use-cases that can be solved with simple abstractions, where programmers are still spinning up threads and locking objects. Most application programmers don't do manual memory management, low-level network programming, graphics, and so on. Why should parallel programming be any different? That is the point I believe the author is making, and I happen to agree.
- mcguire 13y agoOn the other hand, there is a certain undercurrent to this and many similar posts that I've seen, something along the lines of "Because I don't need to do it, no one needs to." Or, in this case, "Synchronization primitives are deep, dark, evil voodoo magic and you'll never be beardy enough to do it right." Such as: "Locks and other synchronization primitives are systems level constructs. People who know a lot more about multithreading use those constructs to build concurrent data structures and higher level synchronization constructs that mere application programmers like you and I use in our programs." ...which is probably true, but there is nothing scary about "systems level" stuff---even the author could probably tool up to do it. That becomes a problem in the 10% of use-cases (which I suspect is more frequent than that) where the simple abstractions are not satisfactory.