Chrome parallelism

If you haven't used Google's new Chrome browser, it's definitely worth looking at. The team at Google has written a browser that tries to address some of the shortcomings of other modern browsers. Each part of a web page, the renderer, the JavaScript engine, plugins, etc. all operate in their own processes. This lets each component be isolated from one another in separate address spaces. So when Flash crashes, or Acrobat gets exploited, other tabs keep on going. (I believe the latest Internet Explorer also does something similar to this.) Having separate processes also helps reduce memory fragmentation.

Compare this with the dominant method for writing parallel programs: shared memory with locks and condition variables. That system is fast, but plagued with problems. Shared memory doesn't enforce exclusive access: the programmer is responsible for getting the right locks. When she doesn't, data races happen. If she gets the ordering of some locks wrong, deadlocks could happen. If locks are too fine-grained, she might introduce atomicity violations. And if one thread fails, what can you do if it's holding locks and has left shared state inconsistent?

A simpler life exists: do not share memory, and use explicit communication between concurrent processes. Instantly, locking goes away. No deadlocks, no data races. Failure handling becomes simpler, since no state can be corrupted.

This kind of model is used in the Erlang language, and microkernels have featured these benefits for years. Erlang was developed to be exceptionally fault-tolerant, and still drives critial hardware systems (in addition to Facebook's IM application). These systems haven't been used extensively in part because shared memory is fast. (And perhaps because of Erlang's syntax.) As a result, we researchers try to replay data races quickly and design fault-tolerant wrappers for Linux kernel modules.

I'm glad to see a significant desktop application decide that fault-tolerance and isolation is more important than raw speed.