[concurrency-interest] Locking a ConcurrentHashSet in a ConcurrentHasHMap

Mike Bean bean at alcatel-lucent.com
Fri Aug 8 11:24:52 EDT 2008


Tom,

Using a concurrent map and set allow observers to iterate data structure 
without blocking adds and removes.  I had considered cloning set and 
using conditional replace but sets could be large.  If set is large the 
probability of collisions with other threads becomes greater slowing 
update of set due to other threads replacing set at same time.

I'm also exploring the idea of reworking a copy of ConcurrentHashMap 
code to allow for a multiple values per key.  The get method would 
return a collection of values by walking the entire list for a hash code 
looking for matching keys.  No sure if I will run into problems and I 
always worry about getting the logic right on concurrent data structures.

Thanks for your response,

Mike

Michael Bean (Mike)
Alcatel-Lucent
AAA Product Group
3461 Robin Ln, Ste 1
Cameron Park, CA 95682
Email: bean at alcatel-lucent.com
Phone: 530 672 7577
Fax: 530 676 3442



Tom Hawtin wrote:
> Mike Bean wrote:
>>
>> I was wondering if anyone had some thoughts on how to avoid a lock to 
>> allow removal of a ConcurrentHashSet from a ConcurrentHashMap.  
>> Context is an index manager with these two calls:
>
> I guess you could use a doNotUse flag in a subclass of 
> ConcurrentHashSet. Set the flag before removing the set. Check the 
> flag after adding to it.
>
> If only we had a standard full set of multiset collections and the 
> like...
>
>> I'm also concerned at the memory cost of a ConcurrentHashSet for a 
>> single reference to an Entry object but the indexing and unindexing 
>> entries gets more complex with the map containing an Entry or a 
>> ConcurrentHashSet of Entries.
>
> Are you sure you are going to have significant contention given the 
> map? Perhaps a plain set with synchronisation would do. Or an 
> immutable [by convention] set.
>
> Tom
>


More information about the Concurrency-interest mailing list