[concurrency-interest] int in the ForkJoin example
ashwin.jayaprakash at gmail.com
Mon Aug 8 13:30:03 EDT 2011
I was trying to walk through the code to try and understand where that
barrier could be doing its thing. Obviously the FJ module is fairly complex,
but I'd appreciate it if someone could point to where/how it forces a
consistent read after all the recursive jobs are done.
Is it the synchronized(this) in FJTask.externalAwaitDone() or somewhere in
> ---------- Forwarded message ----------
> From: Doug Lea <dl at cs.oswego.edu>
> To: concurrency-interest at cs.oswego.edu
> Date: Sat, 06 Aug 2011 09:43:05 -0400
> Subject: Re: [concurrency-interest] int in the ForkJoin example
> On 08/05/11 19:43, Ashwin Jayaprakash wrote:
>> The Fork-Join example/doc shows an int being written to by multiple
>> task writes to a separate location in the array, but how is it valid
>> being marked as volatile or using AtomicIntegerArray?
> As mentioned in the ForkJoinTask documentation,
> it is only valid if the tasks each access distinct locations
> before joining. See in particular the javadoc for "fork()", saying:
> "Subsequent modifications to the state of this task or any data it operates
> on are not necessarily consistently observable by any thread other than the
> one executing it unless preceded by a call to join() or related methods, or
> a call to isDone() returning true. "
> Internally, the guarantees about ordering and visibility upon
> joins (as well as related methods like invoke) are arranged
> via volatile/atomic operations that are similar to the ones
> used for similar guranatees upon unlocking locks.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest