[infinispan-dev] Per-entry lock container

[Dan Berindei]

Awesome, it seems ref counting is all the rage nowadays:
http://stackoverflow.com/questions/7424710/does-winrt-have-garbage-collection:)

Manik, I have been looking at your code and I have modified it to not use
any loops in acquireLock:
https://github.com/infinispan/infinispan/pull/1382#issuecomment-9683327

I think it looks better, now I'm curious if it keeps the same throughput...

Cheers
Dan


On Mon, Oct 22, 2012 at 7:16 PM, Manik Surtani <manik at jboss.org> wrote:

> Wow.  Looks like ref counting is a winner.  Simple local mode test,
> comparing 5.2.0.Beta2 (in red), my fix for ISPN-2381 *without* ref counting
> (in blue) and with ref counting (in green).
>
> Weird that read performance is also affected, as these patches are for the
> lock manager which is not used when reading.  Could be overall resource
> contention that slows down reader threads.
>
>
> On 19 Oct 2012, at 11:07, Manik Surtani <manik at jboss.org> wrote:
>
>
> On 17 Oct 2012, at 18:19, Jason Greene <jason.greene at redhat.com> wrote:
>
>
>
> It's not very fair, because threads that try to lock this key after we
> have removed the lock from the CHM have an advantage compared to threads
> that have been waiting for a while on our lock and now have to acquire the
> lock, unlock, and try again to lock on a new key.
>
>
> Well the locks already aren't fair right? Also aren't the only cases of
> scenario 2 key removal and rollback of a put? So we would be talking
> insert/remove competition on the same key.
>
>
> The key lock's lifecycle is not tied to the entry's lifecycle, instead it
> lives just for the duration of a transaction. As soon as the tx is
> committed/rolled back, the lock is removed, and any tx that was waiting on
> the lock will have to create its own lock.
>
>
> Ah ok so it is a very big problem then. I agree then you need reference
> counting. You want that lock to stay around for as long as you have
> contention.
>
>
> Ok, implemented.  Pls review and comment.
>
> https://github.com/infinispan/infinispan/pull/1382
>
> Cheers
> Manik
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121023/b4ac154b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 48877 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121023/b4ac154b/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 42292 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121023/b4ac154b/attachment-0003.png