Conclusion
My prototyping experience convinced me that, ultimately, getting used to multithreaded programming is going to be a big change. It won't necessarily mean the use of new languages or even new skills. It will require consistent attention to parallelism as a new axis along which things must be made to work and can go wrong.
I suspect the database folks have a real advantage in this concurrency revolution. Unlike most applications, the shared-state nature of databases has meant scaling up to additional users was never as easy as adding racks of additional, yet essentially independent, machines. Databases are already quite good at exploiting true machine parallelism.
To accomplish this, database designers have had to consider issues of concurrency, isolation, and deadlock for every line of code they have written. Soon, this requirement will apply to all of us. It doesn't mean we have to rewrite everything from the ground up, but it could mean we'll have to reconsider every library we use to ask questions about how it will operate (or fail) in a multithreaded world.
Acknowledgments
Thanks go to my colleagues Stan Switzer and Steve Dakin for reviewing drafts of this article and to my employer, Adobe Systems, for the opportunity to perform this work and to write about it.
DDJ
