[concurrency-interest] ConcurrentHashMapV8

Joe Bowbeer joe.bowbeer at gmail.com
Wed Oct 5 19:12:26 EDT 2011

On Wed, Oct 5, 2011 at 3:31 PM, David M. Lloyd wrote:

> On 10/5/11 6:11 AM, Doug Lea wrote:
>> I'm still contemplating changes in handling null-returns
>> in the new compute methods. But in the mean time, here
>> is another tiny corner-case issue that is handled differently
>> in ConcurrentHashMapV8 than in the existing j.u.c version.
>> I consider it just a misfeature-fix, but Joe Bowbeer remains
>> nervous about it, so urged me to post and solicit reaction.
>> This takes a fair amount of context to set up:
>> [...snip...]
>> For example,
>> you would be surprised and unhappy if you did
>> Object[] a = myArrayList.toArray();
>> a[0] = 17;
>> and then found out that this caused myArrayList.get(0)
>> to also now return 17.
>> In the case of ConcurrentHashMap, this means that the
>> kind of Entry you get for the elements of entrySet.toArray
>> should NOT write back to the map you got them from.
>> In other words:
>> Object[] a = myMap.entrySet().toArray();
>> (Entry[])a[0].setValue(17);
>> should not change myMap.get(keyFor0) to return 17.
> I disagree with this conclusion; these scenarios aren't really the same.
>  The general contract of toArray() is to return an array consisting of all
> the values in the collection - I think interpreting it such that it can
> return copies of the values is a stretch.  I can't think of any case where
> we'd actually copy the values in normal collections; I don't see why an
> entry set should be any different, magical write-through notwithstanding.
> For example if I did:
> Object[] a = myMap.entrySet().toArray();
> I would expect the same result as if I did:
> Object[] a = new ArrayList<Entry<Blah,Blah>>(**
> myMap.entrySet()).toArray();
> I don't think toArray should be special here.  I think this is the "most
> correct" interpretation of this requirement, and in any case is the one I've
> adhered to whenever developing collection implementations.  I think that
> there should be no difference between the values in a toArray() result and
> the values you'd get back from a set iterator.
> --
> - DML

I agree with your interpretation and expectation regarding toArray.  But the
Map.Entry documentation (below) limits their validity to the duration of the
iteration.  How do you reconcile the two?


"The *only* way to obtain a reference to a map entry is from the iterator of
this [entry-set] collection-view. These Map.Entry objects are valid *only*
for the duration of the iteration; more formally, the behavior of a map
entry is undefined if the backing map has been modified after the entry was
returned by the iterator, except through the setValue operation on the map

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20111005/67e2a88e/attachment.html>

More information about the Concurrency-interest mailing list