[infinispan-dev] Per-entry lock container

[Paolo Romano]

Another alternative solution would be to have a STM-backed 
implementation of a hash table. For instance, some colleagues of mine 
have developed a B+ tree implementation using JVSTM [1].

Benchmarking the performance of such a solution should be relatively fast.

Common sense suggests that a specialized fined-grained locking 
implementation, such as the one Jason mentioned, should be able to 
deliver better performance than a STM-backed one... but that would be 
definitely an interesting experiment to perform!

Cheers,

      Paolo

[1] http://web.ist.utl.pt/~joao.cachopo/jvstm/

On 10/16/12 5:38 PM, Jason Greene wrote:
> On Oct 16, 2012, at 10:33 AM, Sanne Grinovero <sanne at infinispan.org> wrote:
>
>>> But still, since the process of creating, acquiring and adding the lock to the lock map needs to be atomic, and not just atomic but also safe with regards to competing threads (say, an old owner) releasing the lock and removing it from the map (also atomic), I think a concurrent map isn't good enough anymore.
>> are you sure that adding + creating + acquiring needs to be atomic?
>>
>> I see several solutions by using the standard CHM; assuming you
>> already checked for Lock existence:
>> - create a Lock, use a putIfAbsent to store it, then *try* to acquire it
>> - create a Lock, acquire it, putIfAbsent to store it, throw your
>> instance away if you failed to store it and try again by starting over
>> from _get_ to lock on an eventually created new instance.
> Yes if you get the ordering right, it can certainly be done. You might have to introduce a state-based CAS or secondary lock though for some scenarios (I haven't thought through them all) I think Manik's point though was just that getting it right is harder than just making the whole thing atomic.
>
>> What I don't like of this is that you need to get/put on the same key
>> multiple times, hashing the key over and over, looking up the same
>> segment again and potentially traversing segment locks for each of
>> these steps: the V8 solution from Jason looks like far more efficient.
>
> V8 also has some other advantages. It does not use segments, so you don't have to tune it. It also uses less memory, and it can deal with collisions much better.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev