Forums Register Login

util.concurrent

+Pie Number of slices to send: Send
Hi

I am using ClockDaemon.executePeriodically from Doug lea's library.

in the call to above method we provide the period as an argument which specifies the period for timed call to the command.

Here I have 2 queries regaring the method

1. what happens when the timer expires when the previous call to command is still not returned.

2. Does the library create new thread each time the timer expires or it places all the commands in single thread. If so in which thread it uses.

Thanks in advance for any help

Swapnil
+Pie Number of slices to send: Send
Try posting in Doug Lea's blog.
+Pie Number of slices to send: Send
Um, before bothering the author, I would recommend doing a little research. The API for ClockDaemon tells us at the very top: "Objects of this class maintain a single thread and a task queue..." That answers the second question directly.

For the first question, since there's only one thread, I would think that the ClockDaemon has no choice other than to wait until the task is completed. The API for executePeriodically() also says "It is generally a bad idea to use a period that is shorter than the expected task duration." But it doesn't say exactly what happens. Fortunately you have the source, since that's how the package is distributed. Of you can write simple tests to see what happens. E.g.

[ July 17, 2007: Message edited by: Jim Yingst ]
+Pie Number of slices to send: Send
Thanks Jim..

I have checked the program. New commands waits in a queue and executes once the previous command is over.

Now my problem is: If the previous command is still running and the timer expires resluting in new command in queue than this command should be removed from queue.

Thanks in advance.
+Pie Number of slices to send: Send
Hm, I don't see a good way to do that using the existing classes. Probably the easiest thing to do here is modify the code. Note the statement included in the comment at the top of the class:

So, do what you want with it! I'd make a copy of ClockDaemon (perhaps called ClockDaemon2 (because I can't think of a good name for the change you want) and modify the code as necessary. It looks like all you need to do is go near the end of the nextTask() method (line 329 in my copy) and replace

with

Here 100 is an arbitrary small amount of milliseconds that are considered "close enough" to the desired time that it's still acceptable to execute the task. The preceding code would have forced a wait() if (now < when) so now we already know that (now >= when). It's unreasonable to expect that (now == when) exactly (thread timings aren't that precise, generally) so here the choice is that as long as a task is less than 100 milliseconds late, it can still be executed. Hence, require that (now < when + 100) Otherwise that task is discarded, and the nextTask() method will loop again to find the next scheduled task. Which sounds like it's probably what you want. Hope that helps...
[ July 18, 2007: Message edited by: Jim Yingst ]
Nothing up my sleeve ... and ... presto! A tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com


reply
reply
This thread has been viewed 836 times.
Similar Threads
Time-based responses in a JFrame?
Killing current TimerTask
Flow of Code Control
terminate of programs
thread started a process, now what?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 08:09:14.