[concurrency-interest] Simple ScheduledFuture problem
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
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
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...
More information about the Concurrency-interest