[concurrency-interest] Simple ScheduledFuture problem

Tim Peierls tim at peierls.net
Wed Aug 30 22:02:39 EDT 2006

On 8/30/06, Dhanji R. Prasanna <dhanji at gmail.com> wrote:
> On 8/31/06, Dawid Kurzyniec <dawidk at mathcs.emory.edu> wrote:
> > 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.
> >
> > 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.
> yes, but presumably a more elegant solution is for the other "setting
> methods" to invoke the single setter, and treat the volatile field as
> a javabeans property.
> Just my 20c that we should be encouraging this approach. =)

Encouraging what approach? I can only think of two approaches for a pre-Java
5 AtomicInteger:

1. Volatile value, unsynchronized get, synchronized setters.
2. Non-volatile value, synchronized get *and* setters.

I'm not sure which of these is more "elegant", but Dawid presumably chose #1
at least partly on the grounds that the backport is intended for use on
platforms where volatile reads are likely to be cheaper than synchronizing
around a non-volatile read.

I hasten (too) to add, would it break atomicity if the synchronized
> setter were called concurrently (say from a different class)? I assume
> yes.

Not sure what you mean: it wouldn't be much of an AtomicInteger if its
methods couldn't be called concurrently.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060830/85ca1d0b/attachment.html 

More information about the Concurrency-interest mailing list