.jpg)
Multicore Prelude
This is a comment made by "Joe Armstrong", the author of book "Programming Erlang". I thought this would be useful for all of us to get an idea about the current situation out there.
How can we write programs that run faster on a multicore CPU? It’s all about mutable state and concurrency.
Back in the old days (twenty-odd years ago), there were two models of concurrency:
- Shared state concurrency
- Message passing concurrency
The programming world went one way (toward shared state). The Erlang community went the other way. (Few other languages followed the “message passing concurrency” road. Others were Oz and Occam.)
In message passing concurrency, there is no shared state. All computations are done in processes, and the only way to exchange data is through asynchronous message passing.
Why is this good?
Shared state concurrency involves the idea of “mutable state” (literally memory that can be changed)—all languages such as C, Java, C++, and so on, have the notion that there is this stuff called “state” and that we can change it. This is fine as long as you have only one process doing the changing. If you have multiple processes sharing and modifying the same memory, you have a recipe for disaster—madness lies here.
To protect against the simultaneous modification of shared memory, we use a locking mechanism. Call this a mutex, a synchronized method, or what you will, but it’s still a lock.
366
If programs crash in the critical region (when they hold the lock), disaster results. All the other programs don’t know what to do. If programs corrupt the memory in the shared state, disaster will also happen. The other programs won’t know what to do.
How do programmers fix these problems? With great difficulty, of course. On a unicore processor, their program might just work; but on a multicore— Disaster!
There are various solutions to this (transactional memory is probably the best), but these are at best kludges. At their worst, they are the stuff of nightmares.
Erlang has no mutable data structures:1
• No mutable data structures = No locks
• No mutable data structures = Easy to parallelize
How do we do the parallelization? Easy. The programmer breaks up the solution of the problem into a number of parallel processes.
This style of programming has its own terminology; it’s called concurrency- oriented programming.
1. That’s not quite true, but it’s true enough.
