[concurrency-interest] Significance of volatile for Objects

Joe Nguyen jnguyen at automotive.com
Fri Mar 7 12:15:05 EST 2008


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



More information about the Concurrency-interest mailing list