Here’s a conversation I seem to be having over and over these days:
Someone else: Computers are getting more and more cores. So, we need to thread our software to take advantage of them.
Me: But threads (the Dijkstra style shared-state-with-locks-and-mutexes-and-semaphores-oh-my variety) are almost impossible to get right, and when they’re used in other than the simplest way, its easy to get random deadlocks that happen every few months/years.
Someone else: Computers are getting more and more cores, so we need threads.
Me: But there are other forms of concurrency. Processes that communicate using files, pipes, sockets, or even shared memory. Or software transactional memory (hell, people use databases for IPC now, so STM can only be better), or message passing.
Someone else: … ?
A few days later:
Someone else: Let’s talk about how to multi-thread our code.
Sorry people. As Sutter and Larus say:
“humans are quickly overwhelmed by concurrency and find it much more difficult to
reason about concurrent than sequential code. Even careful people miss possible interleavings among even simple collections of partially ordered operations.”
And as Edward A Lee says:
“[Threads] discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism.”
[Clever summary encouraging people to understand concurrency more closely.]