A Generic/Templatized ThreadPoolExecutor

[Ashwin Jayaprakash-2]

Hi, I was wondering if it would be a good idea to genericise the j.u.c.ThreadPoolExecutor to accept a sub-type of Runnable. I mean:
 
From:
class ThreadPoolExecutor{
  ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
  }
}

To:
class ThreadPoolExecutor<R extends Runnable>{
  ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<R> workQueue) {
  }
}

Several times, I've felt the need to create a specific class like a.b.c.AsyncJob that implements Runnable which is scheduled on the thread-pool. But I had to cast the return values of shutdownNow() or the parameter for beforeExecute(R r, Throwable t) and afterExecute(R r, Throwable t). Has anyone else faced this?

Thanks,
Ashwin (http://www.javaforu.blogspot.com)

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[Joe Bowbeer]

On Fri, Aug 21, 2009 at 1:10 PM, Ashwin Jayaprakash wrote:

Hi, I was wondering if it would be a good idea to genericise the j.u.c.ThreadPoolExecutor to accept a sub-type of Runnable. I mean:
 
From:
class ThreadPoolExecutor{
  ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
  }
}

To:
class ThreadPoolExecutor<R extends Runnable>{
  ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<R> workQueue) {
  }
}

Several times, I've felt the need to create a specific class like a.b.c.AsyncJob that implements Runnable which is scheduled on the thread-pool. But I had to cast the return values of shutdownNow() or the parameter for beforeExecute(R r, Throwable t) and afterExecute(R r, Throwable t). Has anyone else faced this?

I see your point, however, note that if you submit Runnable tasks using any of the submit or invoke methods, or via a CompletionService, then the items on the work queue will be RunnableFutures created by the executorService's newTaskFor method.

Joe

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[Gregg Wonderly-2]

Joe Bowbeer wrote:

> On Fri, Aug 21, 2009 at 1:10 PM, Ashwin Jayaprakash wrote:
>
>     Hi, I was wondering if it would be a good idea to genericise the
>     j.u.c.ThreadPoolExecutor to accept a sub-type of Runnable. I mean:
>      
>     *From:*
>     class ThreadPoolExecutor{
>       ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long
>     keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
>       }
>     }
>
>     *To:*
>     class ThreadPoolExecutor<R extends Runnable>{
>       ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long
>     keepAliveTime, TimeUnit unit, BlockingQueue<R> workQueue) {
>       }
>     }
>
>     Several times, I've felt the need to create a specific class like
>     a.b.c.AsyncJob that implements Runnable which is scheduled on the
>     thread-pool. But I had to cast the return values of shutdownNow() or
>     the parameter for beforeExecute(R r, Throwable t) and afterExecute(R
>     r, Throwable t). Has anyone else faced this?
>
>
>
> I see your point, however, note that if you submit Runnable tasks using
> any of the submit or invoke methods, or via a CompletionService, then
> the items on the work queue will be RunnableFutures created by the
> executorService's newTaskFor method.

This is one of those odd things to me.  The fact that the Runnable itself needs
to be wrapped, and you can't deal with the wrapping class to find the "data"
that you put into your "Runnable" is really a pain because you then have to
create a map from Future to Runnable at the point of submission to get back to
your Runnable's Data so that as Futures complete, you can handle any post run
cleanup.

Gregg Wonderly
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[Joe Bowbeer]

I agree that it can be odd.

However, the Runnable doesn't "need" to be wrapped.  It can be executed directly by any Executor.  OTOH, the Runnable "will" be wrapped if you submit or invoke it.

I personally prefer to create my own Runnables (usually a subclass of FutureTask) and execute them directly.  This requires a little more setup initially, but it provides full control.

Note that the newTaskFor method was added later to help folks create their own FutureTask specific variants even when they use the submit and/or invoke methods.

Joe

On Fri, Aug 21, 2009 at 4:10 PM, Gregg Wonderly wrote:

Joe Bowbeer wrote:

On Fri, Aug 21, 2009 at 1:10 PM, Ashwin Jayaprakash wrote:

   Hi, I was wondering if it would be a good idea to genericise the
   j.u.c.ThreadPoolExecutor to accept a sub-type of Runnable. I mean:
       *From:*
   class ThreadPoolExecutor{
     ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long
   keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
     }
   }

   *To:*
   class ThreadPoolExecutor<R extends Runnable>{
     ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long
   keepAliveTime, TimeUnit unit, BlockingQueue<R> workQueue) {
     }
   }

   Several times, I've felt the need to create a specific class like
   a.b.c.AsyncJob that implements Runnable which is scheduled on the
   thread-pool. But I had to cast the return values of shutdownNow() or
   the parameter for beforeExecute(R r, Throwable t) and afterExecute(R
   r, Throwable t). Has anyone else faced this?



I see your point, however, note that if you submit Runnable tasks using any of the submit or invoke methods, or via a CompletionService, then the items on the work queue will be RunnableFutures created by the executorService's newTaskFor method.

This is one of those odd things to me.  The fact that the Runnable itself needs to be wrapped, and you can't deal with the wrapping class to find the "data" that you put into your "Runnable" is really a pain because you then have to create a map from Future to Runnable at the point of submission to get back to your Runnable's Data so that as Futures complete, you can handle any post run cleanup.

Gregg Wonderly

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[Ashwin Jayaprakash-2]

I guess newTaskFor() and RunnableFuture are some consolation - I hadn't noticed these new classes. I'm still on 1.5 :-( This will definitely save the expense of creating too many little wrapper objects - Future, Runnable..

However, RunnableFuture does not implement Callable. So, for such cases you'd have to create and wrap the actual "job" with a Future. It still looks a little weird to me - so many interfaces.

Still, I think it should've been templatized.

Thanks!
Ashwin.

---------- Forwarded message ----------
From: Joe Bowbeer <joe.bowbeer@...>
To: concurrency-interest <concurrency-interest@...>
Date: Fri, 21 Aug 2009 17:40:36 -0700
Subject: Re: [concurrency-interest] A Generic/Templatized ThreadPoolExecutor
I agree that it can be odd.

However, the Runnable doesn't "need" to be wrapped.  It can be executed directly by any Executor.  OTOH, the Runnable "will" be wrapped if you submit or invoke it.

I personally prefer to create my own Runnables (usually a subclass of FutureTask) and execute them directly.  This requires a little more setup initially, but it provides full control.

Note that the newTaskFor method was added later to help folks create their own FutureTask specific variants even when they use the submit and/or invoke methods.

Joe

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[David Holmes-6]

I think if you check the mailing list archives this has come up before and there are reasons why generics can not be used.

 

David Holmes

-----Original Message-----
From: concurrency-interest-bounces@... [mailto:concurrency-interest-bounces@...]On Behalf Of Ashwin Jayaprakash
Sent: Saturday, 22 August 2009 11:40 AM
To: concurrency-interest@...
Subject: Re: [concurrency-interest] A Generic/Templatized ThreadPoolExecutor

I guess newTaskFor() and RunnableFuture are some consolation - I hadn't noticed these new classes. I'm still on 1.5 :-( This will definitely save the expense of creating too many little wrapper objects - Future, Runnable..

However, RunnableFuture does not implement Callable. So, for such cases you'd have to create and wrap the actual "job" with a Future. It still looks a little weird to me - so many interfaces.

Still, I think it should've been templatized.

Thanks!
Ashwin.

---------- Forwarded message ----------
From: Joe Bowbeer <joe.bowbeer@...>
To: concurrency-interest <concurrency-interest@...>
Date: Fri, 21 Aug 2009 17:40:36 -0700
Subject: Re: [concurrency-interest] A Generic/Templatized ThreadPoolExecutor
I agree that it can be odd.

However, the Runnable doesn't "need" to be wrapped.  It can be executed directly by any Executor.  OTOH, the Runnable "will" be wrapped if you submit or invoke it.

I personally prefer to create my own Runnables (usually a subclass of FutureTask) and execute them directly.  This requires a little more setup initially, but it provides full control.

Note that the newTaskFor method was added later to help folks create their own FutureTask specific variants even when they use the submit and/or invoke methods.

Joe

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[Ashwin Jayaprakash-2]

Yeah, I read it now. For others - http://cs.oswego.edu/pipermail/concurrency-interest/2003-August/000515.html

Ashwin.

On Fri, Aug 21, 2009 at 6:46 PM, David Holmes <davidcholmes@...> wrote:

I think if you check the mailing list archives this has come up before and there are reasons why generics can not be used.

 

David Holmes

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

[Gregg Wonderly-2]

The bigger issue for me, is that ThreadPoolExecutor<T extends Runnable> actually
allows me, as a developer to get very specific with typing so that I can make
sure the right things are scheduled into the right queues.

Referring back to my commentary about the VAX VMS scheduling application, I
sometimes use multiple executors to manage differing queues of differing run
length objects, and new and old developers working on such software can often,
by mistake, put the wrong type task into the wrong executor because typing is
not "tight" enough to make sure that the correct tasks are going into the
correct places.

Gregg Wonderly

Ashwin Jayaprakash wrote:

> Yeah, I read it now. For others -
> http://cs.oswego.edu/pipermail/concurrency-interest/2003-August/000515.html
>
> Ashwin.
>
>
>
> On Fri, Aug 21, 2009 at 6:46 PM, David Holmes <davidcholmes@...
> <mailto:davidcholmes@...>> wrote:
>
>     I think if you check the mailing list archives this has come up
>     before and there are reasons why generics can not be used.
>      
>     David Holmes
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest@...
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://cs.oswego.edu/mailman/listinfo/concurrency-interest