| I've written on this problem before: https://kevinlawler.com/parallel One issue is that the pthread model is too low level (think AND and OR gates), but you must include it for completeness. I agree with the comments here that say higher-level multithreading support needs to be "baked in" to the language. Grand Central Dispatch did a good job of raising the bar here, but has its own problems, and is arguably too low level. Another issue is that existing, widespread languages are too old to have cooked higher-level threading support in. You really have to do it from the start. C++ bolt-on parallelism might as well be syntactic sugar. Newer languages, like Rust, have attempted to solve concurrency problems but failed - it's not clear that the designers genuinely understand concurrency at all. Goroutines solve one limited issue of many and seem about as difficult as asking programmers to write threaded programs. To do this correctly you need a new language that cooks it in from the start. There is a laundry list of things that have to be done precisely. It might be possible to do this by rewriting a reference implementation of an existing popular language, but the development overhead and performance concerns involved in backwards-compatibility make that probably infeasible. (Python can't even escape it's global-interpreter lock.) So likely the language that solves this problem is either unwritten or unknown. Other mentions in the comments here: ThreadSanitizer: It's not very good, nor can it be. Erlang: solves the problem, but the actor formulation is too awkward for all but Erlang-specific use-cases. |
Err? I mean, it requires rethinking a bunch of the lessons you learn when concurrency is hard and expensive and to be minimized, sure. But when concurrency is easy and cheap and to be embraced, a bunch of things become a lot easier and more natural to write.
My go to example, from a production system, was a complicated task scheduling system (with user and hardware interrupts to handle). Sure, we could have written it using threads and a priority queue or something...instead we just had one Erlang process per task, with interrupts routed to that process as messages (and linked timer processes that fired messages to those processes for the scheduled stuff, essentially just another type of interrupt/message). Super simple to write, super simple to reason about, never had any sort of race condition or locking issues, across years of development and production use.