Using the threading Package
Using the threading Package
The threading package in the Jakarta Commons project is a package used to help the programmer write threading applications. We have not yet discussed it because within this package are many routines that are useful for when you are writing asynchronous applications. In the Using the Java Classes Observer and Observable section of this chapter, we outlined the observer and callback mechanism. Consider the problem of having to send a notification to 10 observers. The creator of the notification will have to wait until all 10 observers have processed the message. This is a bottleneck and therefore should be optimized. Within the threading package there are such algorithms.
Technical Details for the threading Package
Tables 6.1 and 6.2 contain the abbreviated details necessary to use the threading package.
| Item | Details |
|---|---|
| CVS repository | |
| Directory within repository | threading |
| Main packages used | org.apache.commons.threading |
jakarta-commons-sandbox | Class/Interface | Details |
|---|---|
| [threading].AsyncPublisher | A publisher class used to manage the various subscriptions. |
| [threading].Notifier | A class used by the publisher to send an event to an individual subscriber. |
| [threading].Subscriber | A class that is implemented by the programmer to receive subscription events. |
| [threading].FIFONotifier | A default notifier class used to send an event to an individual subscriber, which uses a background thread. |
| [threading].Alarm | A specific implementation of a publisher that does not accept individual events to propagate but that generates events. The event is triggered based on a time period having passed. |
Rewriting the Observer Using Asynchronous Threads
Recall that we talked about the Observer example in the Using the Java Classes Observer and Observable section. Now, we can entirely rewrite it using the same logic but with interfaces and classes from the threading package. We would rewrite the class Result as shown in Listing 6.11.
 |
class ResultSubscriber implements Subscriber { public void receive(Object published) { Long result = (Long)published; } } | |
In Listing 6.11, the class ResultSubscriber implements the Subscriber interface instead of the previous Observer interface. The threading package does not implement the Observer concept, but rather the Publish and Subscribe concepts. Both concepts are identical, except their names are different. For the interface Subscriber , the method receive has to be implemented. The method receive has one published parameter; it represents the object created by the publisher.
The subsystem does not derive from the class Observable , but rather from the class AsyncPublisher . Both Observable and AsyncPublisher do the exact same thing, except that AsyncPublisher uses a background thread to delegate the notification. Listing 6.12 is an implementation of the subsystem.
| |
class SubSystemThreading extends AsynchPublisher { private Operation _operation = null; public SubSystemThreading( Operation op) { _operation = op; } public void operation( long num1, long num2) { long result = _operation.doSomething(num1,num2); Long longResult = new Long( result); send( longResult); } } | |
In Listing 6.12, the implementation of the method operation has a small change from Listing 6.1 in that the method send is called. The parameter passed to the method send is the object that represents the data to be sent to the individual subscribers. Everything is wired together as shown by Listing 6.13.
| |
SubSystemThreading subsys = new SubSystemThreading( new MyOperation()); subsys.subscribe( new ResultSubscriber()); subsys.operation( 1, 2);
| |
In Listing 6.13, you add a subscriber to the list by using the method subscribe .
Managing the Notification Process
In the threading package, the interface Notifier magically makes everything work. The class AsyncPublisher assumes that the notifier used is the default implementation FIFONotifier . The class FIFONotifier is a first-in first-out notification that delegates the tasks to a thread running in the background. The purpose of the interface Notifier is to handle the delegation of the event. The class AsynchPublisher manages the collection of observers. When a notification is triggered, the class AsynchPublisher will delegate the physical notification to the interface Notifier . At that point, the actual implementation of the interface Notifier can decide to do whatever is correct. Listing 6.14 shows a synchronous implementation of the interface Notifier .
| |
class MyNotifier implements Notifier { private String _name = "MyNotifier"; public int getPriority() { return 0; } public int size() { return 0; } public void setName(String newName) { _name = newName; } public String getName() { return _name; } public void start() { } public void stop() { } public void setPriority(int newPriority) { } public void send(Subscriber subscriber, Object published) { subscriber.receive(published); } } | |
The implementation of the interface Notifier has been reduced to the implementation of the method send . In that implementation, the subscriber is sent the object to be used as a notification object. The rest of the methods relate to how to control the delegation subsystem. The interface Notifier assumes that an implementation will be using some type of subsystem to delegate notifications.
The subsystem could be thread-based or process-based; it is up to the subsystem. In any case, the subsystem is responsible for calling the subscriber with a notification object. To start and stop the subsystem, you use the methods start and stop , respectively. The creator of the notification must be the one to start and stop the subsystem. The methods setPriority and getPriority are used to set the priority of the subsystem. The numbers assigned to the property priority are entirely dependent on the subsystem's implementation. The method size is used to retrieve how many notifications still need to be sent out.
Other Kinds of Notifications
The threading package has two other types of publishers. The class SynchPublisher is a direct counterpart to the classes Observer and Observable because all notifications are sent out in a serial manner without any background thread. While it would seem odd to add the class SyncPublisher to the Java classes if the processing actions are the same, the advantage is that it simplifies subbing in different notification implementations .
Another useful notification is the class Alarm . The class Alarm is a notification that does not accept any notifications (as is shown in Listing 6.13). The class Alarm accepts only subscribers that will be notified once the time has expired . An example of using the class Alarm is shown in Listing 6.15.
| |
Alarm alarm = new Alarm(Alarm.ONE_SHOT, 1000); alarm.subscribe( new AlarmSubscriber()); alarm.start();
| |
In Listing 6.15, the class Alarm is instantiated with one parameter. The parameter is the number 1000 , which defines the number of milliseconds that will pass before the alarm will trigger. The alarm can be put into three modes: continuous, one shot, or multiple one shot. When the alarm is set to continuous mode , a notification is sent every time period. When the alarm is set to either one shot or multiple one shot mode, a single notification is generated when an alarm is triggered.
The difference between a one shot and multiple one shot is how the background thread is managed. For all modes, a background thread that manages the notifications is executed. In the case of one shot mode, which is used in Listing 6.15, the background thread exits when the notification has finished. In multiple one shot mode, it does not exit the background thread. Regardless of whether you use one shot or multiple one shot mode, you can restart the alarm using the class method Alarm.start . To stop the alarm, the class method Alarm.stop is called.
EAN: 2147483647
Pages: 109