[infinispan-dev] Eviction overhaul

Thu Apr 2 11:31:52 EDT 2009

Ok, taking this further.  After some discussion with Jason, there  
actually is a better concurrent linking algorithm we can use that is  
simpler and more efficient (no spin locks or auxillary nodes), but a  
bit more delicate with node states.  THis is what is used in the  
linking in JDK6's ConcurrentSkipListMap, but I've quite heavily  
modified it for our purposes.  Not implemented this as yet, but here  
are the ideas for you guys to tear apart.  Looking forward to your  
feedback.  :-)

Concurrent ordered data container (for FIFO, LRU containers)
--------------------------------------------------------------------------------

The main constraints on this container are that it should provide  
constant time operations for get(), contains(), put() and remove()  
operations, and the iterator should be ordered and offer constant time  
traversal.

This implementation is based on threadsafe linked lists used in  
ConcurrentSkipListMap (CSLM) in Sun's JDK 6.  In addition, the  
implementation uses a lockable Segment array (as in CHM) except that  
in the HashEntries, keys are always Object and values are  
LinkedEntries (LEs).  LEs always have a reference to an  
InternalCacheEntry, as well as volatile next and prev pointers.

Also, unlike CSLM Nodes, LEs are doubly linked since to update the  
link on the predecessor, we need a reference to it (as LEs are located  
via a hash lookup rather than traversal).  This alters the logic of  
insertions and removals somewhat.

Removal
-------
1.  Lock segment containing key
2.  Locate LinkedEntry using a hash lookup
3.  If this is null, or its value is null, return null.
4.  CAS LE.value to null.  If this fails, ignore and return.  Someone  
else is probably removing it.
5.  Unlink.  If unlinking fails, ignore and continue; will be marked  
and removed later.
6.  Release segment lock

Unlink
------
1.  Create Marker LE (MLE)
2.  MLE.next = LE.next
3.  CAS LE.next to MLE (expecting MLE.next)
4.  CAS LE.prev.next to MLE.next (expecting LE)
5.  On failure to CAS, ignore

Insertion
---------

1.  Lock segment containing key
2.  Create new LE, populate with value, insert into hash table
3.  Insert link
4.  Release segment lock

Insert link
-----------
1.  LE.next = HEAD
2.  LE.prev = HEAD.prev
3.  CAS HEAD.prev = LE (if HEAD.prev == LE.prev)
4.  If the CAS fails, start again at step 4
5.  LE.prev.next = LE (if LE.prev.next = HEAD)

Update (E.g., for LRU visit or update)
------
1.  Lock segment containing key (only if update)
2.  if LE == null || LE.value == null return
3.  if update, update value.  No need for a CAS here since we have a  
segment lock
4.  CAS LE.prev.next = LE.next (expecting LE, ignore failure)
5.  CAS LE.next.prev = LE.prev (expecting LE, ignore failure)
6.  insert LE
7.  Release segment lock (if update)

Get
---
1.  Retrieve LE
2.  if (LE.value==null) unlink LE, return null.

On 2 Apr 2009, at 10:00, Manik Surtani wrote:

>
> On 2 Apr 2009, at 09:10, Mircea Markus wrote:
>
>> Manik Surtani wrote:
>>> Hello all.
>>>
>>> I have finished my work with the eviction code in Infinispan, here is  
>>> a summary of what has happened.
>>>
>>> From a user perspective (including API and configuration) as well  
>>> as a design overview, please have a look at
>>> http://www.jboss.org/community/docs/DOC-13449
>>>
>>> From an implementation perspective, have a look at the srcs of  
>>> FIFODataContainer and LRUDataContainer.  These two classes are  
>>> where everything happens.  The javadocs should explain the  
>>> details, but in a nutshell you can expect constant time operations  
>>> for all puts, gets, removes, iterations.  :-)
>>> Feedback on the impls would be handy.  :-)
>> I like to concept - it's nice and clear for users to grasp. Also  
>> took a look at implementation, nice and complex, so I'd rather have  
>> you and a white board to understand it completely :) .
>> Some notes though: EvictionException is never used, same for  
>> SpinLock.rl field.
>
> Good point, EvictionException was a carry-over from JBC which can go  
> away.
>
> SpinLock.rl was something I used for debugging/tracking race  
> conditions - it should go away now as well.
>
>> And a question:
>> with this impl, we're doing locking twice for cache operations: on  
>> LockInterceptor and on DataContainer itself. Why is this necessary?  
>> I think this is needed so that eviction thread and user threads not  
>> to conflict( am I right?).
>
> Well, the locking is done on a different level.  The  
> LockingInterceptor locks a key.  So keep in mind that 2 threads may  
> lock 2 separate keys concurrently, but these may map to the same  
> hash bucket in the data container.  In which case, since the DC uses  
> a CHM, this would mean that the same stripe is locked preventing  
> concurrent reorganisation of the stripe.
>
>> Isn't it possible to use the same locking (i.e. LockManager) for  
>> both these threads?
>
> Possible, but again not ideal, for example if you have TX 1 which  
> writes to key K1.  The way this currently works, here is what happens:
>
> 1.  Acquire lock for key K1 in the lock manager
> 2.  Write to K1
> 3.  Sleep?
> 4.  Commit:
> 5.  Write changes to DC.  This will lock the stripe in the CHM for  
> the duration of this step only.
> 6.  Release lock acquired in 1
>
> Now if you have a concurrent write to K2, which *happens* to be in  
> the same stripe as K1 in the CHM, this second thread will *not*  
> block for TX 1 since TX 1 only locks the CHM stripe for a short  
> duration (step 5 above).
>
> Now if we used the same locks thoughout (e.g., step 1 *is* the lock  
> stripe in the CHM) then you have far less concurrency.
>
> Of course, the above premise only holds true if you have enough  
> shared locks for the lock manager such that K1 and K2 do not map to  
> the same lock, even if they are in the same stripe in the CHM.  Also  
> holds true if lock striping is disabled and you have a lock per key.
>
>> (also, why are we using  ConcurrentHashMaps in default container -  
>> isn't access to data guarded by the lock interceptor?
>
> See above.  :-)
>
> Cheers
> Manik
>
> --
> Manik Surtani
> Lead, JBoss Cache
> http://www.jbosscache.org
> manik at jboss.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik at jboss.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090402/5efcb4e5/attachment-0001.html 