[concurrency-interest] HalfSync

Allan Kielstra kielstra at ca.ibm.com
Wed May 24 17:49:41 EDT 2006

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

concurrency-interest at cs.oswego.edu

[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 ?


Concurrency-interest mailing list
Concurrency-interest at altair.cs.oswego.edu

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

More information about the Concurrency-interest mailing list