[concurrency-interest] Feedback requested: virtual threading on top of a thread-pool

Joe Bowbeer joe.bowbeer at gmail.com
Fri Feb 9 14:53:12 EST 2007


Matthias wrote:
>
> I would welcome feedback on any blatant problems in the code or whether
> this functionality could have been implemented more easily with existing
> concurrency classes.
>

Is your ThreadedExecutor similar to the SerialExector example in the
Executor javadoc?

http://java.sun.com/javase/6/docs/api/java/util/concurrent/Executor.html


On 2/9/07, Ernst, Matthias <matthias.ernst at coremedia.com> wrote:
>
> I've implemented an Executor implementation that provides for
> "threading" on top of another Executor. Its application fits well with
> Peter's description in a recent thread:
>
> Peter Veentjer:
> > Create an Executor with a single thread and let this thread
> > communicate with the structure (if the structure is accessed by a
> > single thread, you don't need concurrency control in the structure
> > itself).
>
> If I have many "structures" I don't want to have one single-threaded
> executor per structure but use a pool. The pool should however garantuee
> that jobs _for a particular structure_ are never executed concurrently.
> Thus my design: a ThreadedExecutor has a linked queue of jobs and can
> tell whether a command is currently executing on its behalf in the
> delegate thread pool.
>
> Enqueuing a job into the ThreadedExecutor, if idle, enqueues a
> corresponding worker into the delegate pool. This worker will execute
> jobs on behalf of that queue until empty and atomically fall back to
> idle.
>
> Thus you can combine single-threaded access to data structures and still
> leverage thread-pooling.
>
> I would welcome feedback on any blatant problems in the code or whether
> this functionality could have been implemented more easily with existing
> concurrency classes.
>


More information about the Concurrency-interest mailing list