[concurrency-interest] Simple ScheduledFuture problem

Dawid Kurzyniec dawidk at mathcs.emory.edu
Wed Aug 30 20:11:24 EDT 2006


Brian Goetz wrote:
>>> I hasten to add that if the setter is simply of the form:
>>>
>>> synchronized void set(int newValue) {
>>>    field = newValue;
>>> }
>>>
>>> and field is volatile, then making the setter synchronized is unnecessary.
>>>       
>> This was pretty much my whole argument =)
>>     
>
> Right.  What David was getting at is the case where you want to do some 
> sort of nontrivial update, like increment.  The modification 
> operation(s) use synchronized to make them atomic, and the read 
> operations use volatile to reduce the cost / improve the scalability 
> where reads outnumber writes.  Like a read-write lock, but cheaper.
>
> As you've pointed out, this is a very fragile pattern -- if using it, 
> document it carefully!

Just my 2c (to explicitly point out what David and Brian smuggled 
between the lines): the synchronization on setter can only be skipped if 
there are no other setters. For instance, in the AtomicInteger in 
backport-util-concurrent:

private volatile int value;
public final int get() { return value; }
public final synchronized void set(int newValue) { value = newValue; }
public final synchronized int getAndAdd(int delta) {
    int old = value; value += delta; return old;
}

It is tempting to drop "synchronized" from set(newValue), but it would 
be wrong: it would break atomicity of read-modify-write methods such as 
getAndAdd etc. by allowing set(newValue) to perform the update in the 
middle.

Regards,
Dawid



More information about the Concurrency-interest mailing list