[concurrency-interest] ScheduledThreadPoolExecutor woes

Bela Ban belaban at yahoo.com
Thu Jan 18 11:20:04 EST 2007

Ernst, Matthias wrote:
> Bela,
> #1: this is addressed in Java 6 with a short timeout +
> http://java.sun.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExe
> cutor.html#allowCoreThreadTimeOut(boolean)
> I'm only assuming that it applies to ScheduledTPE as well.

Excellent, good to know !

> #2: In that case I'll have the tasks reschedule themselves:
> run() {
> ... pool.schedule(this, remaining);
> }

This is something I thought of too, but it is somewhat kludgy for a task 
to have knowledge of the pool and to reschedule itself. Although this is 
done in ScheduledThreadPoolExecutor.ScheduledFutureTask.runPeriodic() too:

|private void runPeriodic() {
            boolean ok = ScheduledFutureTask.super.runAndReset();
            boolean down = isShutdown();
            // Reschedule if not cancelled and not shutdown or policy allows
            if (ok && (!down ||
(getContinueExistingPeriodicTasksAfterShutdownPolicy() &&
                        !isTerminating()))) {
                long p = period;
                if (p > 0)
                    time += p;
                    time = now() - p;
// <<<<<==== here*
            // This might have been the final executed delayed
            // task.  Wake up threads to check.
            else if (down)

It would be great if there was a scheduleXXX() method which took an 
Period parameter:

|scheduleAtFixedRate(Runnable command, long initialDelay,  Period 
period, TimeUnit unit)|

with Period being

|public interface Period {
   long get();

Then the code above would simple call:

|long p = period.get();

|rather than|

||long p = period;|

Bela Ban
Lead JGroups / JBoss Clustering team
JBoss - a division of Red Hat

More information about the Concurrency-interest mailing list