IMHO, it can be fixed by making HashEntry.value a
volatile member.
Please note that one can get
map.entrySet().iterator(), and directly change objects
there. Since there is no lock on HashEntry.setValue(),
it must be, at least, volatile member.
thanks,
Doron.
--- Doug Lea <dl@cs.oswego.edu> wrote:
>
> > > Thread1:
> > > Object o = new ...
> > > map.put("x", o);
> > >
> > > Thread2:
> > > Object value = map.get("x");
> > >
> > > Although the map itself is fine, the user
> objects
> > > passing through it are invalid.
> >
> > ..
> > I talked with Doug, and we believe this is a
> problem.
>
> To be clearer, initialization in "new ..." won't be
> reordered past
> the CAS inside the lock in put, given how JSR166
> locks happen to work
> on current platforms. So this problem doesn't arise
> in practice. But
> the implementation should be changed to compliantly
> preclude this and
> other similar problems, so that it is guaranteed to
> work.
>
> Doran, thanks for pointing this out!
>
> -Doug
>
>
> -------------------------------
> JavaMemoryModel mailing list -
http://www.cs.umd.edu/~pugh/java/memoryModel
=====
Doron Rajwan, mailto:doron@rajwan.org
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT