[concurrency-interest] Significance of volatile for Objects

David Holmes dcholmes at optusnet.com.au
Fri Mar 7 15:58:01 EST 2008


The visibility guarantees come from the interaction of volatile writes and
volatile reads. In this code fragment there is only one volatile write -
when the HashMap is created. Thus as Peter states the newly created HashMap
is visible to subsequent accesses.

But any operations on the HashMap only involve a volatile read, so there are
no further visibility guarantees.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Joe
> Nguyen
> Sent: Saturday, 8 March 2008 3:15 AM
> To: Peter Veentjer; pavitar at pramati.com
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Significance of volatile for Objects
>
>
> Therefore, volatile in this case doesn't guarantee the visibility then
> (even in java 1.5)?
>
> "Visibility:
> It makes sure that thread that reads data, sees the most recently
> written value of data. It also makes sure that the reading thread sees
> all values written (e.g. the member variables of the hashmap) before the
> writing thread did the write to data. This last behavior is available
> since Java 1.5 (JMM 133). It is a technique that can be used to
> 'transfer' objects from one thread to another in a thread safe manner. A
> BlockingQueue for example support this behavior."
>
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Peter
> Veentjer
> Sent: Friday, March 07, 2008 4:48 AM
> To: pavitar at pramati.com
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Significance of volatile for Objects
>
> >  But then doing operation on HashMap like put. It doesnt mean write to
> the
> >  volatile field.Siimilarly a get shouldnt mean read from volatile.
>
> That is correct. If one thread does a put (so a write inside the
> internals of the hashmap) and another thread does a get (so a read
> from the internals of the hashmap) there could be visibility problems
> because there is no happens before relation between the put and the
> get (there is no happens before relation between 2 reads of the same
> volatile variable).
>
> So:
> -changes made to the internal structure of the hashmap done by the
> write, don't have to be visiblity when you do a get.
> -objects placed in the put can't be safely passed from one thread to
> another because of the lack of the happens before relation.
>
> So if you are lucky enough to have missed the 'classic' concurrency
> problems with this hashmap, there are still JMM problems.
>
>
>
> Is it
> >  correct or i am missing something here.
> >
> >
> >  Regards
> >  Pavitar
> >
> >
> >
> >
> >  > Volatile helps to prevent 2 issues:
> >  >
> >  > reorderings
> >  > visibility.
> >  >
> >  > Reordering:
> >  > it prevents that the created hashmap is assigned to the data
> variable,
> >  > before the constructor has run. So it prevents other threads from
> >  > seeing a partly constructed hashmap.
> >  >
> >  > Visibility:
> >  > It makes sure that thread that reads data, sees the most recently
> >  > written value of data. It also makes sure that the reading thread
> sees
> >  > all values written (e.g. the member variables of the hashmap)
> before
> >  > the writing thread did the write to data. This last behavior is
> >  > available since Java 1.5 (JMM 133). It is a technique that can be
> used
> >  > to 'transfer' objects from one thread to another in a thread safe
> >  > manner. A BlockingQueue for example support this behavior.
> >  >
> >  > For more information I suggest "Java Concurrency in Practice"
> >  >
> >  > PS:
> >  > I know you made the remark, but for other less experienced
> developers
> >  > reading this thread.. the example is not threadsafe because HashMap
> is
> >  > not threadsafe. So its internal structure could be corrupted by
> >  > concurrent access.
> >  >
> >  > On Fri, Mar 7, 2008 at 10:04 AM, Pavitar Singh
> <pavitar at pramati.com>
> >  > wrote:
> >  >> Hi,
> >  >>
> >  >>  If i have something like this:
> >  >>
> >  >>  volatile Map data = new HashMap();
> >  >>
> >  >>  then what are the gurantees provided by volatile.
> >  >>
> >  >>  I know this is wrong usage of volatile. But i just wanted to know
> >  >>  gurantees provided by volatile in case of Objects.
> >  >>
> >  >>  Regards
> >  >>  Pavitar
> >  >>  _______________________________________________
> >  >>  Concurrency-interest mailing list
> >  >>  Concurrency-interest at altair.cs.oswego.edu
> >  >>  http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >  >>
> >  >
> >
> >
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> 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