[concurrency-interest] Simple ScheduledFuture problem

David Holmes dcholmes at optusnet.com.au
Tue Aug 22 20:34:22 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.

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