12 Replies Latest reply: May 22, 2012 3:26 AM by Patcha RSS

    timer.scheduleAtFixedRate can stack?

    Patcha
      Hi all, I'm using the following code in the <tt>main()</tt> of a <tt>Frame</tt> extending class:
      Timer timer = new Timer();
      timer.scheduleAtFixedRate(new TimedRefresh(), 50, 50);
      The question is: how can I be sure that the task will not repeat itself after 50 millis, before the old call of "<tt>run()</tt>" ends up calculations?

      Praticall in the run() there are stuffs which can take different time to be made, so I don't wanna lower the time it repeats the task.
      But when it takes longer, I wanna be sure a new task will not being started.

      <tt>Timer</tt> and <tt>TimedRefresh</tt> already supports this?

      Thank you!
        • 1. Re: timer.scheduleAtFixedRate can stack?
          rp0428
          >
          Timer and TimedRefresh already supports this?
          >
          The Javadocs for those methods tell you what they support and have the answer to your question.
          • 2. Re: timer.scheduleAtFixedRate can stack?
            Patcha
            Ok, you're obviously right.
            (Strange... usually I read javadoc... this time I didn't carefully).

            But in the javadoc I found that TimedRefresh schedule uses to not wait anymore, when calculation of previous <tt>run()</tt> exceed the repeat delay you set up.
            So if I set up 50 and <tt>run()</tt> takes 60 millis, next <tt>run()</tt> will be immediate.

            Seeing that my <tt>run()</tt> also contains <tt>repaint()</tt> for the <tt>awt Frame</tt>, I think this is what generates some lil graphical issue to me (if second <tt>run()</tt> is very fast to reach <tt>repaint()</tt> I get two <tt>repaint()</tt> too close).

            There is a way I can ensure a minimum granted delay between each <tt>run()</tt>, even when previous <tt>run()</tt> exceed delay time?
            • 3. Re: timer.scheduleAtFixedRate can stack?
              rp0428
              >
              There is a way I can ensure a minimum granted delay between each run(), even when previous run() exceed delay time?
              >
              You might want to consider using a ScheduledExecutorService instead of a timer.

              They allow tasks to be scheduled with a fixed delay as well as a fixed rate.
              http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ScheduledExecutorService.html
              • 4. Re: timer.scheduleAtFixedRate can stack?
                Patcha
                I read javadoc you linked for <tt>ScheduledExecutorService</tt>, but this time I failed to understand if it can happens two Thread goes run together.

                I mean, if I set delay 50, and first Thread takes 60 to ends up, it makes this and the following Thread overlap for 10 seconds? (As I don't wish.)
                Or it counts 50 after first Thread surely finished, even if it takes 60? (As I wish.)

                I can't understand this.
                • 5. Re: timer.scheduleAtFixedRate can stack?
                  EJP
                  I read javadoc you linked for <tt>ScheduledExecutorService</tt>, but this time I failed to understand if it can happens two Thread goes run together.
                  I quote: "If any execution of this task takes longer than its period, then subsequent executions may start late, but will not concurrently execute.". Strange you missed it.
                  • 6. Re: timer.scheduleAtFixedRate can stack?
                    Patcha
                    Well... actually if I go here: http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ScheduledExecutorService.html
                    then search for "longer" word (CTRL+F) I find nothing... so I don't see the sentence you quoted... you read it in the javadoc directly or inside that web-page?

                    I read that web-page... I supposed it was the same than javadoc.

                    Anyway, does that means if the previous Thread is not ended up, the following Threads will not run?
                    • 7. Re: timer.scheduleAtFixedRate can stack?
                      EJP
                      Patcha wrote:
                      Well... actually if I go here: http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ScheduledExecutorService.html
                      then search for "longer" word (CTRL+F) I find nothing... so I don't see the sentence you quoted... you read it in the javadoc directly or inside that web-page?
                      If I go here or here I can read it, as I did.
                      Anyway, does that means if the previous Thread is not ended up, the following Threads will not run?
                      "Will not concurrently execute" seems perfectly clear to me.
                      • 8. Re: timer.scheduleAtFixedRate can stack?
                        Patcha
                        Ok got the point... I'll test it.

                        Thank you!

                        PS: The original web-page link was from javadoc 1.5. There wasn't that sentence.
                        Strange.
                        • 9. Re: timer.scheduleAtFixedRate can stack?
                          EJP
                          Strange that somebody tightened up the Javadoc? Why?
                          • 10. Re: timer.scheduleAtFixedRate can stack?
                            Patcha
                            'Cause surely also in Java 1.5 there should be a kind of behaviour in case of thread taking longer.
                            So they could update Javadoc 1.5 web-page, too.
                            • 11. Re: timer.scheduleAtFixedRate can stack?
                              EJP
                              Maybe there isn't such a guarantee in Java 5. Maybe there is but they didn't get around to it yet. Maybe they never will. Maybe retrospectively altering the Javadoc of a version released eight years ago is a bad idea.
                              • 12. Re: timer.scheduleAtFixedRate can stack?
                                Patcha
                                Ok. Doesn't really matter actually, and it's out of topic.

                                You simply said you felt strange how possible I missed such sentence... and I answered it: I missed it 'cause accidentally I read Javadoc reference for 1.5, and there wasn't such sentence there.

                                Thank for you help.
                                Bye!