Adept Software Development

Adept: (A)pplication (D)evelopment (E)nterprise to (P)ersonal (T)ransition. It is a system I am developing to leverage Enterprise developer skills to produce stand-alone software for other market segments. This is a general software development blog discussing issues about project, architecture, design and development. The emphasis will be in Java, but many of the issues will be more general. Almost all will be technical.

http://marringtons.com

Wednesday, April 27, 2005

The Semaphore

Java makes multi-tasking easy with the synchronised keyword. This can be applied to a method as part of the signature or used to wrap a code block, by providing an instance to synchronise against. If a second thread attempts to enter a synchronised section, it's blocked until the first one completes.

This is all well and good, but Java prior to 1.5 did not provides semaphores. A semaphore is a flag that will cause a thread to wait until another thread tells it to continue. I use semaphores as much as, if not more often than, synchronised blocks.

I use semaphores in CGI so that the HTTP server thread can wait until the external program completes. The HTTP server itself has a waitUntilClosed method that can be used to block the main thread until the server itself signals completion. Semaphores are also invaluable in the database code so that index generation, physical writes and housekeeping can be done in the background, yet concerned threads can be put on hold when necessary.

Before semaphores it was common, although always considered bad practice, to write a polling loop. This is a loop that just keeps checking for a desired result until it comes out positive. Polling loops are always a bad idea because they eat CPU time like it's going out of style, and do very little by comparison.

All Java objects have wait and notify methods that provide all the functionality. In the Adept Library I have chosen to wrap these in a Semaphore object for convenience - and, as always, to make the code easier to read. This object handles interrupts and allows for cases where resume() can be called before pause().

If a thread is core to the interactive components of an application, it's a good idea for it to not block forever. Perhaps the thread that was to resume the process has died or become lost - in multi-threading, anything can happen. Of course this generates code similar to a polling loop, but if the wait period is long enough there will not be a serious performance cost.

In summary, if you need to wait for something to happen, use semaphores rather than polling . For a pack of good examples, head over and download the Adept Library.

0 Comments:

Post a Comment

<< Home