[concurrency-interest] Is it a good idea to try manipulating theway JVM reorders?

David Holmes davidcholmes at aapt.net.au
Sat Dec 19 05:04:01 EST 2009


Enno Shioji writes:
> Now, here is a naive optimization attempt that I think is not thread-safe:
>
> class Task {
>     //Populate with bunch of (Long, new AtomicReference()) pairs
>     //Actual app uses read only HashMap
>     Map<Id, AtomicReference<SubTaskResult>> subtasks = populatedMap();
>     AtomicInteger counter = new AtomicInteger(subtasks.size());
>
>     public Task set(id, subTaskResult){
>            //null check omitted
>            subtasks.get(id).set(result);
>            //In the actual app, if !compareAndSet(null, result)
> return null;
>            return check() ? this : null;
>     }
>
>     private boolean check(){
>            return counter.decrementAndGet() == 0;
>     }
>
>   }//class
>
> I concluded a thread can observe a decremented counter (by another
> thread) before the result is set in AtomicReference (by that other
> thread) because of reordering.

Which "another thread" are you referring to? The AtomicInteger has volatile
semantics and will be read and written by all threads storing a result, so
the results can not appear in the Map after the corresponding decrement of
the counter. For each thread the write to the map happens-before the
decrement (program order) and each decrement to a non-zero value must
happen-before the decrement to zero (counter acts as volatile). Consequently
all the results stores must happen-before a zero counter value is seen. I'd
go further and say that any thread that reads the counter value N, must be
able to see the results stored by threads that set a counter value greater
than N.

David Holmes



More information about the Concurrency-interest mailing list