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

Ernst, Matthias matthias.ernst at coremedia.com
Fri Feb 9 14:15:04 EST 2007


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

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.


matthias.ernst at coremedia.com
software architect
+49.40.32 55 87.503

More information about the Concurrency-interest mailing list