4 ms·
Has the author really written lots of multithreaded code? Lots of people think they understand multithreading because they understand the synchronization primi
by ntoshev 17y ago
Has the author really written lots of multithreaded code?
Lots of people think they understand multithreading because they understand the synchronization primitives. "I'll just share this synchronized HashMap among my threads and everything will be fine". Not so. Because your code makes implicit assumptions about that HashMap all the time, e.g. that you can check if an element is in the map and if not, add it (but another thread added it after you checked); that the map won't change and throw an exception while you iterate over it because my loop doesn't change it, etc.
I don't think granularity is the hardest thing about multithreaded programming, it's these implicit assumptions. In an imperative language we just tend to think about our code as if it is single threaded and nothing changes until you change it. Then you get rare and irreproducible bugs in your program.
- lutorm 17y agoI think I agree with both. The impression I got from the article was that even after you've carefully identified all shared datastructures, and made sure they are as few as possible and locked properly, you still have to decide how to structure the parallelization. This will have effects on how it scales to higher # of cores and larger problems and is, in some sense, a less constrained problem because you don't know where to look. At least wrt synchronization, you can make a list of shared data and go through it.
- ntoshev 17y agoThe article says: "You can almost always use a simple locked data-structure for synchronization fairly painlessly (and with a bit of practice, you can usually write one fairly painlessly, too)." If we focus on the first part, in my experience it is wrong: you can't rely on the data structure to do synchronization for you, because these structures only guarantee that internally they will work consistently, not that using them you can forget about synchronization and threading. Quite often you need to do your own synchronization on top of them, and it is easy to miss some cases. That's what my examples are about.
- jrockway 17y agoLots of people think they understand multithreading because they understand the synchronization primitives. Well yeah. But the primitives aren't "synchronized hash maps", they're "transactions".