incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael André Pearce <michael.andre.pea...@me.com>
Subject Re: changing the DM behavior at runtime
Date Sun, 26 Feb 2012 01:42:13 GMT

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
>>> <michael.andre.pearce@me.com> 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/
>>>> 
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message