[concurrency-interest] Simple ScheduledFuture problem

Joe Bowbeer joe.bowbeer at gmail.com
Wed Aug 30 22:07:52 EDT 2006

On 8/30/06, Brian Goetz <brian at quiotix.com> 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!

To be clear: I was suggesting *either* synchronized *or* volatile
(exclusive) originally.

Combining them for synchronized writing and volatile reading hadn't
occurred to me, and would probably confuse me if I saw it in someone
else's code.

(I'm less easily confused by off-the-shelf components with descriptive
names, such as, say, ReentrantReadWriteLock.)

More information about the Concurrency-interest mailing list