views:

1904

answers:

4

Hi all

I have one simple question regarding Java TimerTask. How do I pause/resume two TimerTask tasks based on a certain condition? For example I have two timers that run between each other. When a certain condition has been met inside the task of first timer, the first timer stops and starts the second timer, and the same thing happens when a certain condition has been met inside the task of second timer. The class below shows exactly what I mean:

public class TimerTest {
Timer timer1;
Timer timer2;
volatile boolean a = false;

public TimerTest() {
    timer1 = new Timer();
    timer2 = new Timer();     
}

public void runStart() {
    timer1.scheduleAtFixedRate(new Task1(), 0, 1000);
}

class Task1 extends TimerTask {
    public void run() {
        System.out.println("Checking a");
        a = SomeClass.getSomeStaticValue();

        if (a) {
            // Pause/stop timer1, start/resume timer2 for 5 seconds
            timer2.schedule(new Task2(), 5000);
        }
    }
}

class Task2 extends TimerTask{
    public void run() {
        System.out.println("Checking a");
        a = SomeClass.getSomeStaticValue();

        if (!a) {
            // Pause/stop timer2, back to timer1
            timer1.scheduleAtFixedRate(new Task1(), 0, 1000);
        }

        // Do something...
    }
}

public static void main(String args[]) {
    TimerTest tt = new TimerTest();
    tt.runStart();      
}

}

So my question is, how do I pause timer1 while running timer2 and vice versa while timer2 is running? Performance and timing is my main concern as this needs to be implemented inside another running thread. By the way I am trying to implement these concurrent timers on Android.

Thanks for your help!

+3  A: 

From TimerTask.cancel():

Note that calling this method from within the run method of a repeating timer task absolutely guarantees that the timer task will not run again.

So once cancelled, it won't ever run again. You'd be better off instead using the more modern ScheduledExecutorService (from Java 5+).

Edit: The basic construct is:

ScheduledExecutorService exec = Executors.newSingleThreadScheduledExecutor();
exec.scheduleAtFixedRate(runnable, 0, 1000, TimeUnit.MILLISECONDs);

but looking into it there's no way of cancelling that task once its started without shutting down the service, which is a bit odd.

TimerTask might be easier in this case but you'll need to create a new instance when you start one up. It can't be reused.

Alternatively you could encapsulate each task as a separate transient service:

final ScheduledExecutorService exec = Executors.newSingleThreadScheduledExecutor();
Runnable task1 = new Runnable() [
  public void run() {
    a++;
    if (a == 3) {
      exec.shutdown();
      exec = Executors.newSingleThreadScheduledExecutor();
      exec.scheduleAtFixedRate(task2, 0, 1000, TimeUnit.MILLISECONDS)
    }
  }
};
exec.scheduleAtFixedRate(task1, 0, 1000, TimeUnit.MILLISECONDS);
cletus
Could you show me how to implement the `ScheduledExceutorService` in the class above? thanks
Faiz
It's not the best idea to shutdown the executor service, you can cancel a task via ScheduledFuture returned by scheduleAtFixedRate()
axtavt
@axtavt: `cancel()` will stop a task already running
cletus
@cletus: `cancel(false)` will not
axtavt
A: 

If you have already canceled one timer, you can't re-start it, you'll have to create a new one.

See this answer, it contains a video and the source code how I did something similar.

Basically there are two method: pause and resume

In pause:

public void pause() {
    this.timer.cancel();
}

In resume:

public void resume() {
    this.timer = new Timer();
    this.timer.schedule( aTask, 0, 1000 );
}

That makes the perception of pause/resume.

If your timers perform different actions based on the state of the application you may consider use the StatePattern

Fist define a abstract state:

abstract class TaskState  {
    public void run();
    public TaskState next();
}

And provide as many states as you like. The key is that one state leads you to another.

class InitialState extends TaskState {
    public void run() {
        System.out.println( "starting...");
    }
    public TaskState next() {
         return new FinalState();
    }
 }
 class FinalState extends TaskState  {
     public void run() {
         System.out.println("Finishing...");
     }
     public TaskState next(){
         return new InitialState();
    }
 }

And then you change the state in your timer.

Timer timer = new Timer();
TaskState state = new InitialState();

timer.schedule( new TimerTask() {
     public void run() {
          this.state.run();
          if( shouldChangeState() ) {
              this.state = this.state.next();
           }
     }
 }, 0, 1000 );

Finally, if what you need is to perform the same thing, but at different rates, you may consider using the TimingFramework. It is a bit more complex but let's you do cool animations, by allowing the painting of certain component take place at different rates ( instead of being linear )

OscarRyz
A: 

Reviewing your source code, here are the changes ( which pretty much validate my previous answer )

In task1:

// Stop timer1 and start timer2
timer1.cancel();
timer2 = new Timer(); // <-- just insert this line
timer2.scheduleAtFixedRate(new Task2(), 0, 1000);

and in task2:

// Stop timer2 and start timer1
timer2.cancel();
timer1 = new Timer(); // <-- just insert this other
timer1.scheduleAtFixedRate(new Task1(), 0, 1000);

It runs on my machine:

it works!

OscarRyz
nice background on the terminal window :)
Yar
A: 

In my opinion, this is somewhat misguided. If your code needs time guarantees, you can't use Timer anyway, nor would you want to. "This class does not offer real-time guarantees: it schedules tasks using the Object.wait(long) method."

The answer, IMHO, is that you don't want to pause and restart your timers. You just want to suppress their run methods from doing their business. And that's easy: you just wrap them in an if statement. The switch is on, they run, the switch is off, they miss that cycle.

Edit: The question has shifted substantially from what it was originally, but I'll leave this answer in case it helps anyone. My point is: if you don't care when your event fires in the N millisecond span (just that it doesn't EXCEED once every N milliseconds), you can just use conditionals on the run methods. This is, in fact, a very common case, especially when N is less than 1 second.

Yar