[concurrency-interest] Simple ScheduledFuture problem

Dhanji R. Prasanna dhanji at gmail.com
Tue Aug 22 20:40:09 EDT 2006


On 8/23/06, David Holmes <dcholmes at optusnet.com.au> 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 =)

Dhanji

>
> David
>
> > -----Original Message-----
> > From: concurrency-interest-bounces at cs.oswego.edu
> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of David
> > Holmes
> > Sent: Wednesday, 23 August 2006 10:13 AM
> > To: Dhanji R. Prasanna
> > Cc: concurrency-interest at cs.oswego.edu
> > Subject: Re: [concurrency-interest] Simple ScheduledFuture problem
> >
> >
> > > so the volatile field cant be read when a thread is in its
> > > synchronized setter?
> >
> > Yes it can, but the assignment in the setter is atomic so the
> > semantics are
> > "as if" the read occurred just before or just after the synchronized
> > operation.
> >
> > It's a degenerate case of a read/write lock. You never have to exclude the
> > writer with respect to the reader because the action of the
> > writer is atomic
> > with respect to the reader anyway. Of course that breaks down if more than
> > one assignment were involved.
> >
> > Cheers,
> > David Holmes
> >
> > > On 8/23/06, David Holmes <dcholmes at optusnet.com.au> wrote:
> > > > > Dhanji R. Prasanna writes:
> > > > > Im curious, what is the purpose of declaring flag volatile AND
> > > > > synchronizing setter access to it?
> > > >
> > > > It gives you a simple/crude read/write lock.
> > > >
> > > > David Holmes
> > > >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


More information about the Concurrency-interest mailing list