Re: JavaMemoryModel: Tiger beta1 ConcurrentHashMap bug?

From: Doron Rajwan (doron@rajwan.org)
Date: Mon Apr 05 2004 - 16:27:42 EDT


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