• Post Reply Bookmark Topic Watch Topic
  • New Topic

Timer thread safety  RSS feed

 
Justin Chu
Ranch Hand
Posts: 209
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is technically not about thread safeness of Timer class, but I'm concern about possibility of ActionListener event being fired after timer.stop() is called in the EDT.

Consider the following case:
someTimer.start();
// at about the same split second where event is to be fired...
someTimer.stop();
// action listeners get fired off

Is it possible to have the above scenario happen?
 
Campbell Ritchie
Sheriff
Posts: 55351
157
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not sure, but having looked at the API for javax.swing.Timer, I can't see why you can't have a timer event 1 microsecond before stop() is evoked.
By this time the actionEvent will have been fired, and the actionPerformed() method might not be activated until after the Timer has stopped. It doesn't say anything about thread safety in the Timer API, but it does say quite clearly in the API for most Swing components that they are not thread-safe.

So I think your scenario can happen in real life.
 
Justin Chu
Ranch Hand
Posts: 209
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For instance, I added a job to the timer to blink some button. Now that I want to remove that button, I'd naturally do timer.stop() and then nullify the button.

If calling stop() in the EDT doesn't prevent any event to be enqueued to the EDT, the late action can cause NPE. Of course, this can be solve easily by having more rigorous checking.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Chu Tan:
For instance, I added a job to the timer to blink some button. Now that I want to remove that button, I'd naturally do timer.stop() and then nullify the button.

If calling stop() in the EDT doesn't prevent any event to be enqueued to the EDT, the late action can cause NPE. Of course, this can be solve easily by having more rigorous checking.


I'd bet that this can be coded in a way that "nullifying the button" won't cause a NPE, even without checking for null. Can you show us the code that would cause the NPE?
 
Justin Chu
Ranch Hand
Posts: 209
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If Timer is built into a framework that allows user to add listener and to turn it on/off. It just makes it unpredictable from the developer perspective.

I've looked into Timer's source code, it seems that it is guaranteed.

Even if an event is queued in EDT, prior to firing it always check against a notify boolean.
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Chu Tan:
If Timer is built into a framework that allows user to add listener and to turn it on/off. It just makes it unpredictable from the developer perspective.

I've looked into Timer's source code, it seems that it is guaranteed.


Threads can be VERY unpredictable,... part of the matter arrvies from how machinery operates and usually is distracting from the view of a programmer who does not build machinery for entertainment.

Thread safety should be discussed in Threads and Synchronization , which is moderated by a book author on the subject. There are tools with which this challenge can be effectively moderated or brought within reasonable design margins, that would become somewhat distracting to try to get the design challenge fully and effectively met in the Swing awt discussion forum. I suggest you post a full workup of what you have done on this so far in the Threads discussion forum.

Even if an event is queued in EDT, prior to firing it always check against a notify boolean.


Yes, but there are several issues here. Is this a student project ?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!