FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Java
Email
Print
Reprint

add to:
Del.icio.us
Digg
Google
Furl
Slashdot
Y! MyWeb
Blink
August 02, 2006

Multithreading, Java, & OSGi

(Page 10 of 10)

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

Previous Page | 1 Multithreading in Java & OSGi | 2 Requirements | 3 The Challenge | 4 Problem Solving | 5 ThreadManager Design Points | 6 Multiple Blockers | 7 Interrupt After Run | 8 Interrupt Me Before I Run Again | 9 Interrupted Exceptions | 10 Conclusion
TOP 5 ARTICLES
No Top Articles.



MICROSITES
FEATURED TOPIC

ADDITIONAL TOPICS

INFO-LINK