Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Multithreading in Java & OSGi Requirements The Challenge Problem Solving ThreadManager Design Points Multiple Blockers Interrupt After Run Interrupt Me Before I Run Again Interrupted Exceptions Conclusion

The Challenge

I quickly discovered that coordinating the lifetimes of even a small number of threads (read: two) was easy to get wrong. There are the usual issues with state shared between threads; those can be solved with appropriate synchronization mechanisms. Stopping the threads turns out to be the tricky part.

To make things concrete, an OSGi bundle can implement an interface called BundleActivator, which contains just two methods: start() and stop(). OSGi calls these methods when the bundle is started or stopped. The general rules for implementing these methods are that they must return quickly, they can be invoked on any thread, and they should avoid doing things that could lead to deadlock. For example, a start() method should not attempt to use the OSGi facility for installing a new bundle because that is a long-running operation. Furthermore, because the level of parallelism in the OSGi implementation is not guaranteed, the installation call might block waiting for the start method to return; because install was called from start, deadlock arises.

The bundle is allowed (assuming security permissions are granted) to spawn new threads. However, the stop() method must guarantee that all of these threads have exited before returning. That's the root of the coordination problem.

What can happen if you get this wrong? Just about anything. The OSGi implementation I was working on was throwing ClassNotFoundException exceptions from classes I'd written when they attempted to access other classes I'd written in the same bundle—which meant it couldn't be a classpath problem. That baffled me until I realized the exception was thrown from a thread in my bundle, which was still running after stop() had returned. The OSGi framework, thinking the bundle was stopped, had disconnected the class loaders for that bundle, causing a later request to load classes to fail. (Remember, class loading in Java is lazy.)

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 Next Page

RELATED ARTICLES Widget SDK Released for BlackBerry Agitar Updates JUnit Tool G1: Java's Garbage First Garbage Collector Perforce Releases Pure Java API for SCM Perforce Releases Java Version of Plug-in for Eclipse		TOP 5 ARTICLES No Top Articles.