contain an array of locks (where lockId = lockarray index) and then use the
following bit of black magic to select the lock to return, this allows for
locking safely yet, keeping a spread of threads running concurrently. below is
a pseudo example of how to get a lock for key, default number of locks is 32 as
is same with concurrent hash map.
public class LockHolder<K> {
private final Lock[] locks;
public LockHolder(){
this(32);
}
public LockHolder(int numberOfLocks){
if ((numberOfLocks & numberOfLocks - 1) == 0){
locks = new Lock[numberOfLocks];
//populate array with locks;
} else {
throw new LockHolderExcpetion("number of lucks must be to the power of
2!");
}
}
public Lock getLock(K key)
{
int lockId = hash(key) & numberOfLocks -1;
return this.locks[lockId];
}
/**
* Return hash code for Object key. Since we are using power-of-two
* tables, it is worth the effort to improve hashcode via
* the same multiplicative scheme as used in IdentityHashMap.
*/
protected static int hash(K key) {
int h = x.hashCode();
// Multiply by 127 (quickly, via shifts), and mix in some high
// bits to help guard against bunching of codes that are
// consecutive or equally spaced.
return ((h << 7) - h + (h >>> 9) + (h >>> 17));
}
}
On 26 Feb 2012, at 01:23, Michael André Pearce wrote:
> Haha i knew i remember seeing something, we can take insperation for key
> locking from how concurrenthashmap achieves it.
>
> http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/ConcurrentHashMap.java
>
>
>
> On 26 Feb 2012, at 01:14, Michael André Pearce wrote:
>
>> Doug Lee and using hashes, though i still cant remember for the life of me
>> where ive seen this atm. (it cant be too distant past if i remember the guys
>> name)
>>
>>
>> On 26 Feb 2012, at 01:06, Simone Tripodi wrote:
>>
>>> +1 concurrency is still an open issue in DM
>>>
>>> best,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sun, Feb 26, 2012 at 1:33 AM, Michael André Pearce
>>> <[email protected]> wrote:
>>>> Also can i suggest locking on the key for put/updates/deletes? avoids
>>>> someone getting a key whilst it is in transitive state of being updated by
>>>> another, ive seen before a fancy way of doing this, avoiding a lock for
>>>> every key, will have to try remember.
>>>>
>>>> On 26 Feb 2012, at 00:24, Simone Tripodi wrote:
>>>>
>>>>> Hi all guys,
>>>>>
>>>>> I had a chat with Benoit in another thread and I realized no one of
>>>>> our class is Thread safe - what do you think of actual behavior that
>>>>> every component accepts a setter for any member - that could cause
>>>>> strange behaviors at runtime?
>>>>>
>>>>> I would analyze wich components can be converted to immutable - IIUC
>>>>> Benoit agreed with me on having some PointerImpl members as immutable,
>>>>> i.e. CacheService#setMap( ConcurrentMap<K, Pointer<V>> map ) means
>>>>> dropping all the already stored data :)
>>>>>
>>>>> Thoughts?
>>>>> best,
>>>>> -Simo
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>
>>
>
