Esther Schindler writes:
Programming for multiple threads is not fundamentally different from writing an event-oriented GUI application or even a straight up sequential application, writes Jim Mischel. The important lessons of encapsulation, separation of concerns, loose coupling, etc. all apply.
But developers get into trouble with multiple threads when they don’t apply those lessons; instead they try to apply the mostly-irrelevant bits of information they learned about threads and synchronization primitives from introductory multithreading texts. Mischel focuses on two things that developers do wrong when writing multithreaded code, and explains how to avoid them.
Here's one of them:Probably the most important lesson to be learned from the past 60 years of software development is that global mutable state is bad. Really bad. Programs that depend on global mutable state are harder to reason about and generally less reliable, because there are too many possible ways for the state to change. There is a huge amount of research to back up that generalization, and countless design patterns whose primary purpose is to implement some type of data hiding. The best thing you can do to make your programs easier to reason about is to eliminate as much global mutable state as possible.
Think he's on track? What have you you learned about writing multithreaded code that might save the next programmer from teeth-gnashing?
