Re: Q.: supporting arbitrary DAGs in ForkJoinPool implementation

On 4/29/21 10:25 AM, Godmar Back via Concurrency-interest wrote:
>
> I'm creating 3 tasks called parent, child, and grandchild. The parent 
> forks the child, and the child forks the grandchild. The parent joins 
> the child whereas the grandchild joins the parent. Child does not join 
> the grandchild. In terms of dependencies, grandchild would depend on 
> the parent and parent would depend on the child. This is my attempt at 
> creating an acyclic dependency graph.
>
> My question is whether this is a well-formed workload and if so, 
> whether the FJP implementation should be able to complete it.

Forms of non-strictness involving joins of ancestors are not guaranteed 
to be supported for Recursive{Actions, Tasks}. The dependency graph is 
tracked as fork-graph, under the assumption that it is OK to 
unnecessarily help a descendant task (since the choice to do so is 
intrinsically racy). This is guaranteed to succeed whenever a pure 
recursive single-threaded execution would do so (hence the class names). 
Violations often work anyway unless they also have cyclic join 
dependencies. Your example is the smallest I've seen that sometimes does 
not. We should improve documentation  to better explain this more 
generally. One of the reasons for introducing CountedCompleters and 
other subclasses of ForkJoinTasks is to support less structured 
execution patterns.

-Doug


_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest