[concurrency-interest] missed deadlines.
alarmnummer at gmail.com
Thu Jul 6 22:50:20 EDT 2006
Hmmm.. I have to think about this different approach.
Because the 'scheduling' thread never is blocked for a long period
(unless the executor it uses to execute the tasks on has to much work
to do) tasks are created on time.
But it doesn't mean that a created task is executed directly because
it can be stored in the workqueue of the executor for some time.
If I add an expirationdate to the task when the scheduler creates it
and check the expiration date when it is executed, I could add the
I'm going to think about this approach.. thanx.
On 7/6/06, Tim Peierls <tim at peierls.net> wrote:
> If you have a lot long-running tasks that need scheduling, consider
> splitting the task into two pieces: a trigger task that is scheduled on a
> ScheduledExecutorService, and the main task, which runs in a separate
> ExecutorService. The trigger task is responsible only for executing the main
> task (perhaps after determining whether it is appropriate to do so at all)
> in the second ExecutorService, so it can get out of the way quickly.
> As has been pointed out here before, this kind of design raises its own
> issues. In particular, if you want cancellation of the trigger task to
> cascade to the main task, you need to keep state around in the trigger task.
> I use the scheduled trigger task approach to provide a periodic background
> update of a large data structure. I don't want the update to run in the
> scheduled pool thread, because it could take a while and interfere with
> other scheduled activities. So I schedule a trigger task to execute the
> update in a cached thread pool.
> On 7/6/06, Peter Veentjer <alarmnummer at gmail.com> wrote:
> I have a question regarding missed deadlines and java.util.Timer and
> I'm wondering why there is no functionality for dealing with missed
> deadlines. Within a Timer you have one thread, if a job takes a long
> time, the other tasks are 'queued' untill the long-job has finished.
> When that job finishes, all other queued-jobs are run and I think this
> could lead to some serious issues. I can image you want to have some
> control like:
> -execute it
> -drop it
> -do something else like sending a message.
> The same goes for the ScheduledThreadPoolExecutor. If a job takes a
> long time and a different job needs to be scheduled, a free thread is
> used (if one is available). If no free thread is available, you get
> the same problems as with the Timer.
> Another think I'm wondering about is the fixed size of the threadpool
> of the scheduledthreadpoolexecutor. I can image it would be usefull
> that a threadpool increases if there are no available threads to
> execute a scheduled task and if those 'extra' threads aren't used for
> some time, they could be discarded. Am I missing something?
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest