ach at quartetfs.com
Wed Apr 11 06:10:09 EDT 2012
Hello Doug and All,
This is an exciting addition to the framework. I think it makes the
fork/join pool even more fit for general purpose multithreading. Two years
ago I decided to switch to fork/join pool exclusively to support all the
multi-threading in the "ActivePivot" project (an in-memory analytics
solution). This works pretty well, and we reach far higher multi-core usage
than with standard thread pools.
Yet we still have performance drops with tasks that access shared data and
acquire a lock for that. While the task waits for the lock, it “wastes” its
worker thread that could otherwise do something else. Not much you can do
about it unless you have access to some other work to run after tryLock()
fails. But it gets worse when another task joins the locking task as it may
itself “waste” its worker thread waiting, same thing for the entire chain
of parents… It is possible to reach a state where the pool has most of its
worker threads joining. Counted completers help a lot, because they remove
those intermediary joins.
You have mentioned that counted completers would help with tasks that
perform IO, or last an unpredicted long time. I think they will also better
handle a few locking tasks, more efficiently than a managed blocker that is
often difficult to put in place when the actual lock is hidden.
That being said when rewriting some of our core algorithms with counted
completers, I find it difficult to propagate exceptions. It was very fast
migrating code based on recursive actions, but exceptions thrown in the sub
tasks would be swallowed (also if that makes you skip the tryComplete()
call, joining the root task is an infinite wait). When a sub task fails,
what is the best way to propagate the exception to the parent completer?
On 9 April 2012 16:16, Doug Lea <dl at cs.oswego.edu> wrote:
> After sitting on multiple variations for months, I committed
> CountedCompleter, a completion-based flavor of ForkJoinTask.
> As mentioned a few times over the past year, the main motivation
> is to better support tasks that perform IO or other base
> actions that may (or may not) take a lot of time to execute.
> As is the case with JDK7 async IO and other completion-based
> frameworks, the most common path to efficiency is for such tasks
> to arrange continuation actions that occur upon their completion.
> The main twist for CountedCompleters is that continuations
> might be dependent on multiple actions, not just one. (Or in
> other words, the continuations must be preceded by a specialized,
> "bottom-up" form of join.)
> The CountedCompleter abstract class provides a minimal basis
> for these kinds of tasks. While some of the mechanics are
> reminiscent of other FJ-like frameworks such as Intel TBB,
> CountedCompleters are designed to fit smoothly with other
> kinds of ForkJoinTasks (like RecursiveActions), and so still
> allow people to use the more pleasant Future-style conventions
> rather than count-based bottom-up joining unless they need them.
> At the same time, the CountedCompleter class exposes enough
> mechanics to allow all sorts of tweaks that people can use
> to improve performance.
> In particular, in addition to usually being the best way to deal
> with IO etc bound tasks, CountedCompleters sometimes fare better
> than RecursiveActions in programs that entail lots of garbage
> collection because GC can have similar impact on task variability.
> Even though targeted for JDK8, versions of CountedCompleter
> appear in the jsr166y and main repositories, not jsr166e. This is
> because they require a non-public hook into modified ForkJoinTask
> exception handling mechanics in order to properly propagate
> exceptional completions. For sources, docs, and jar files, see
> the usual links at http://gee.cs.oswego.edu/dl/**
> The API docs include more details and some examples:
> I also added a few (with more to come) test/demo programs that illustrate
> other usages. See CCBoxedLongSort and CCJacobi in
> Please try these out. As always, comments and suggestions
> (hopefully based on usage experience) would be welcome.
> Concurrency-interest mailing list
> Concurrency-interest at cs.**oswego.edu <Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest