[concurrency-interest] Locking a ConcurrentHashSet in a ConcurrentHasHMap
bean at alcatel-lucent.com
Fri Aug 8 11:24:52 EDT 2008
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,
Michael Bean (Mike)
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
>> 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.
More information about the Concurrency-interest