[concurrency-interest] Questions on ConcurrentHashMap

Grace Kwok gykwok at gmail.com
Wed Nov 28 02:13:00 EST 2007


Thanks.

> Yes and no. You are correct on the possible result set, but incorrect that
> for a synchronized HashMap the result would always be [null, null].

Okay, thanks for the info.   I was being unclear.  In my
implementation, I synchronized with a sychronized block on a HashMap (
for methods get, put , clear) so the results are [null, null] in my
case and I want to keep this behavior.

Thanks, Grace



On Nov 27, 2007 10:53 PM, David Holmes <dcholmes at optusnet.com.au> wrote:
> Hi Grace,
>
> > 1) Consider these operations on a populated map:
> > - map.clear() is called
> > - immediately or concurrently afterwards map.get(A) and
> > map.get(B) are called.
> >
> > We know for sure that if map is a synchronized HashMap, the result of
> > A and B would be null.
> >
> > However, if map is a concurrentHashMap, the results of get(A) and
> > get(B) could be any of the followings [AResult, BResult], [null,
> > null], [AResult, null], [null, BResult].  Am I correct?
>
> Yes and no. You are correct on the possible result set, but incorrect that
> for a synchronized HashMap the result would always be [null, null].
>
> It all depends on the timing of get relative to the clear:
>
> - clear -> get(A) -> get(B)  => [null, null]
> - get(A) -> clear -> get(B)  => [AResult, null]
> - get(B) -> clear -> get(A)  => [null, BResult]
> - get(A) -> get(B) -> clear  => [AResult, BResult]
>
> With ConcurrentHashMap the timing window is different - clear becomes
> clear-reaches-the-point-of-locking-segment-A/B - but the possible outcomes
> are the same.
>
> > 2) I have a map cache that behaves as such:
>
> No comment on this part.
>
> Cheers,
> David Holmes
>
>
>


More information about the Concurrency-interest mailing list