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 <sa...@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
