Dispatching work that's executed in some predefined order

[Robert Nicholson-3]

Can somebody critique these two approaches?

You have a runnable with a work queue and it's work queue is processed  
in it's run method. How there is no interation.  Just poll for the  
first element and if there's no element run returns.

This runnable is then a task that's put in the work queue of an  
executor service such that the executor service manages the threads  
which are assigned to each task. The run method simply calls poll on  
the runnables work queue and takes the first item it can find in the  
work queue and executes that. So other items in the work queue will be  
processed the next time the executor service gives a thread to this  
runnable. Secondly the number of these tasks is unbounded ie. if one  
doesn't exist already (by some differentiator) it's created on the fly  
otherwise an existing one is used. I think the idea is that if the  
runnable isn't processing tasks it can still queue future submissions  
which are then processed next time run is called on the runnable from  
the executor service.

Contrast this approach with another that simply has N tasks running  
which poll a blocking queue for each task and a simple dispatcher  
based on mod some value is used to submit a job to each of these tasks.

In the first approach the runnable is short live. When a task's work  
queue is empty all references to the task are removed such that the  
task is elligble for collection.

In the second approach it never goes away and is predictably always  
available but limited to some bounds.

It seems to me that there is less overhead and management required if  
the runnable that processes the work queue is longer living and simply  
doesn't have to "come and go" so to speak and little is gained by  
having them being short lived.

Again the executor service's thread pool is used to assign threads  
that will service each of these runnables that each process their own  
work queues.






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

[Joe Bowbeer]

On Wed, Jun 4, 2008 at 6:11 PM, Robert Nicholson wrote:

> Can somebody critique these two approaches?
>
> You have a runnable with a work queue and it's work queue is processed
> in it's run method. However there is no iteration.  Just poll for the
> first element and if there's no element run returns.
>
> This runnable is then a task that's put in the work queue of an
> executor service such that the executor service manages the threads
> which are assigned to each task. The run method simply calls poll on
> the runnables work queue and takes the first item it can find in the
> work queue and executes that. So other items in the work queue will be
> processed the next time the executor service gives a thread to this
> runnable. Secondly the number of these tasks is unbounded ie. if one
> doesn't exist already (by some differentiator) it's created on the fly
> otherwise an existing one is used. I think the idea is that if the
> runnable isn't processing tasks it can still queue future submissions
> which are then processed next time run is called on the runnable from
> the executor service.
>
> Contrast this approach with another that simply has N tasks running
> which poll a blocking queue for each task and a simple dispatcher
> based on mod some value is used to submit a job to each of these tasks.
>
> In the first approach the runnable is short live. When a task's work
> queue is empty all references to the task are removed such that the
> task is elligble for collection.
>
> In the second approach it never goes away and is predictably always
> available but limited to some bounds.
>
> It seems to me that there is less overhead and management required if
> the runnable that processes the work queue is longer living and simply
> doesn't have to "come and go" so to speak and little is gained by
> having them being short lived.
>
> Again the executor service's thread pool is used to assign threads
> that will service each of these runnables that each process their own
> work queues.
>

The second option sounds like a fixedThreadPool or a set of
singleThreadExecutors, where each worker thread is executing a single
runnable instance that operates on a private queue.

I don't understand the description of the first option.  In
particular, I don't understand how new short-lived tasks are created.

A code sketch of the first option could make this clearer.

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