[concurrency-interest] Simple ScheduledFuture problem

Brian Goetz brian at quiotix.com
Wed Aug 30 16:29:44 EDT 2006

>> 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!

More information about the Concurrency-interest mailing list