On 23 Oct 2012, at 12:53, Dan Berindei <[email protected]> wrote:
> 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 Nice. Thanks. > I think it looks better, now I'm curious if it keeps the same throughput… Running a new benchmark…. stay tuned. > > Cheers > Dan > > > On Mon, Oct 22, 2012 at 7:16 PM, Manik Surtani <[email protected]> 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. > > <local_gets_all_included.png><local_puts_all_included.png> > > On 19 Oct 2012, at 11:07, Manik Surtani <[email protected]> wrote: > >> >> On 17 Oct 2012, at 18:19, Jason Greene <[email protected]> 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 >> [email protected] >> twitter.com/maniksurtani >> >> Platform Architect, JBoss Data Grid >> http://red.ht/data-grid >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > [email protected] > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani [email protected] twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
