[concurrency-interest] ForkJoinTask enhancement suggestion

Wolfgang Baltes wolfgang.baltes at laposte.net
Mon Mar 5 10:47:44 EST 2012


Thanks, Doug, for the quick reply. I look forward hearing more about 
this. In the meantime, I will look for the posts you refer to.

W.

On 2012-03-05 03:39, Doug Lea wrote:
> On 03/04/12 23:26, Wolfgang Baltes wrote:
>>  My
>> proposal is to consider adding a new constructor ForkJoinTask(V) that 
>> a) sets
>> the value, and b) sets the state to NORMAL. Although it may be 
>> consistent to
>> also add a constructor to create an "exception task", I do not think 
>> this is
>> necessary because of less frequent use, and hence less overall 
>> performance impact.
>>
>> Noticing that tagging will also be available in a forthcoming version 
>> of the
>> framework, it may make sense - for better performance and consistency 
>> - to also
>> add the constructor ForkJoinTask(V, short) and the method complete(V, 
>> short),
>> which allow setting both the value and the tag simultaneously.
>>
>
> Stay tuned. One of the reasons for adding integrated tagging support
> is to allow introduction of one or more new flavors of
> ForkJoinTask (besides RecursiveAction and RecursiveTask)
> that trigger completion actions when some number (including zero)
> of subtasks complete. So you should be able to efficiently get these
> kinds of effects using these classes without us having to expose
> more representation-dependent methods/constructors.
>
> These upcoming classes are part of the efforts I mentioned in posts
> around 6 months ago to improve support for the many FJ usages
> that have sprung up that fall outside of the initial target
> uses.
>
> -Doug
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


More information about the Concurrency-interest mailing list