|
YOUR FEEDBACK Did you read today's front page stories & breaking news?
SYS-CON.TV |
TOP THREE LINKS YOU MUST CLICK ON Advanced Java Skilled Listening in Java
How to generate events for listeners correctly and efficiently
By: Warren MacEvoy
Aug. 7, 2007 09:00 AM
There are many good resources on using events and implementing event listeners. Unfortunately, there are nearly as many resources that incorrectly or inefficiently implement event generators. These implementations introduce subtle nondeterministic errors, execute slowly, and/or fill the virtual machine with unnecessary garbage. The goal of this article is to address this problem once and for all - as a pattern and code generator for JDKs before 1.5, and as a set of generic types in JDK 1.5 and later.
Here's the rub. These things are often not correctly accounted for:
1. Adding and removing listeners may happen asynchronously. That is, different threads may add or remove listeners at somewhat inconvenient times. These are all issues of correctness. Issues of efficiency are:
1. Most generators spend most of their life sending events (as opposed to adjusting who is listening). The humble truth is, most of the generators in your application are not being listened to by anything, and most of the rest have one listener. For example, of the 18 events generated by a JButton, how many do you actually pay attention to?
Correct Let's see why this is correct. First, the synchronized(lock) blocks synchronized access to the listeners' list. It is very important that only the clone step of send is synchronized. This is because completing a send step may require arbitrary adds or removes. If these adds or removes happen from a different thread compared to the send, they would deadlock if send(Event) is synchronized. To avoid this problem, we copy the listeners list before notifying them, thus eliminating the resource contention. It is also important that we do not use the synchronized keyword in front of the add, remove, and clone methods. This is because using synchronized in front of a method uses the object for mutually exclusive access to the methods. Since you have no control over how the DefaultGenerator will be used, it's pretty easy to set up a deadlock situation by having this public mutex locked by something else. By sticking to an internal private object for a lock, we know we're the only ones who affect it. Safety pays in correctness (which is a good thing), but it suffers from some serious inefficiencies:
1. The listeners list is cloned on every send. Most of the time, nobody changes the listeners during a send, so the clone does not usually matter.
And Efficient To use this DefaultGenerator, we would write:
class MyGenerator
There is more code, but what have we gained? This implementation is also correct, but look at send(), listening() and send(Event): no synchronization, no copies, no type-casts, and we only create an Event if (almost always - see sidebar) we have listeners to receive it. Instead of duplicating the listener list every time a send happens, we make copies when adding and removing from the listeners array. This works because object reference assignment is an atomic action. We use a plain old array because this eliminates unnecessary runtime type casts and the iterator overhead. We have a generator that is still safe, but faster than the naïve safe solution. But it's exactly the kind of code that is easy to get wrong. Why would we want to rewrite something a bunch of times anyway? JDK 1.5 helps us with the use of generics. Instead of using the above pattern again and again for each kind of event, we can write it once and be done. An implementation is given in the resources. With the generics at hand, you can stop worrying about making correct and fast generators and just use them. For example, if you wanted to a DateGenerator that sends the current Date on every tick(), a listener that printed out the date, and some main code to put them together:
class DateGenerator YOUR FEEDBACK
LATEST JAVA STORIES & POSTS
SUBSCRIBE TO THE WORLD'S MOST POWERFUL NEWSLETTERS SUBSCRIBE TO OUR RSS FEEDS & GET YOUR SYS-CON NEWS LIVE!
|
SYS-CON FEATURED WHITEPAPERS MOST READ THIS WEEK SPONSORED BY INFRAGISTICS
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||