4 ms·
Agreed. Many years of effort went into building TSAN because nobody can get shared-memory concurrency right, and whenever someone thinks they can get shared-mem
by kps 4y ago
Agreed. Many years of effort went into building TSAN because nobody can get shared-memory concurrency right, and whenever someone thinks they can get shared-memory concurrency right, TSAN comes along and proves them wrong. Concurrency needs the same rule of thumb as cryptography: do not try to roll your own.
- galangalalgol 4y agoRust talks about fearless concurrency, and IME, if you avoid async await it does provide it, potentially at a cost of lovks or mutex that might not be strictly necessary for your actual use case. Actually IME async await isn't a problem either but I've read it can be an issue. In C++ the patterns I don't see bugs in is thread pools for processing large batches of heterogeneous data, and fine grained parallelism for stuff like vector and matrix operations. But in the latter case it is all library driven, and in the former, it is a really simple pattern.
- kps 4y agoYes, these are alternatives to (and/or implemented on top of) shared-memory parallelism, and mostly much better to work with. To continue the cryptography analogy, it's using experts' cryptography libraries. Sometimes you do need to juggle the razor blades yourself (it's not actually turtles all the way down) but it shouldn't be done lightly.
- ilyt 4y agoBarely related rant but I think async/await type of concurrency is the worst of the bunch and outright malady on the code that infected the mass's brain by its proliferation in JS ecosystem. Even crude message passing leads to far cleaner code architecture.