[concurrency-interest] HalfSync

[Allan Kielstra]

It looks a lot like AtomicInteger in the sense that the read getCount, 
get) is not synchronized.

Without a Just In Time compiler (JIT) HalfSync would probably be very 
slightly faster in the uncontended case because there's no need to call 
down to Unsafe.compareAndSwap).  With a JIT, it's probably too close to 
call.  (In both cases, the incrementing thread gets a lock immediately 
using inlined code and updates "count" or "value.")

HalfSync does make an assumption:  words are written atomically by 
hardware.  That wasn't always a valid assumption.  If that assumption 
doesn't hold, you do lose the atomic nature of AtomicInteger.

Allan Kielstra
IBM Canada Lab
Phone: +1 (905) 413-3558 T/L 969-3558
kielstra at ca.ibm.com




"Hanson Char" <hanson.char at gmail.com> 
Sent by: concurrency-interest-bounces at cs.oswego.edu
24/05/2006 05:07 PM

To
concurrency-interest at cs.oswego.edu
cc

Subject
[concurrency-interest] HalfSync






Consider the code:

// Only the write is synchronized, not the read
public class HalfSync {
    private volatile int count;
 
    public HalfSync(int count) {
        this.count = count;
    }

    public int getCount() {
        return count;
    }

    public synchronized int increment(int delta) { 
        return this.count += delta;
    }
}

As far as I can tell, this code is as thread-safe as it would be the case 
if both the increment() and getCount() are synchronized, but would allow 
higher level of concurrency.  (Similar to CopyOnWriteArrayList). 

How would HalfSync compared to AtomicInteger ?  Which one should perform 
faster ?

Hanson

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060524/26a4c8cb/attachment.html