[concurrency-interest] Problem with using an unbounded map of Mutex lock objects

Greg Luck gluck at gregluck.com
Sat Jun 3 00:57:16 EDT 2006


Yes,

It is a requirement that all operations for key K use the same lock.


On 03/06/2006, at 2:12 PM, Brian Goetz wrote:

>> However with lock striping and a sufficiently high entropy of cache
>> keys (I assume this depends entirely on the target business domain)
>> you could end up with the same bottleneck on one heavily used stripe,
>
> This is true of any hash-based collection.  If you have a poor hash  
> function, performance suffers.  In the worst case:
>
>   public int hashCode() { return 0; }
>
> is a valid hash function, but it turns a hashmap into a linked list.
>
> I'm not quite sure what you have in mind for pooling locks, but I  
> think it was a requirement that all operations for key K use the  
> same lock, which eliminates pooling as an option.
>

Regards

Greg Luck

web: http://gregluck.com
skype: gregrluck
yahoo: gregrluck
mobile: +61 408 061 622



-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20060603/d9901375/attachment-0001.html 


More information about the Concurrency-interest mailing list