[infinispan-dev] Semaphore vs Lock

[Sanne Grinovero]

On 7 March 2012 12:05, Galder Zamarreño <galder.zamarreno at redhat.com> wrote:
> Hi,
>
> I was reading up about Java's Semaphores (http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Semaphore.html) and a couple of ideas came to my mind:
>
> 1. Wouldn't it make sense to use binary semaphores instead of locks in Infinispan? We're already having to override ReentrantLock in order to have locks owned by Transactions rather than threads. Initially I thought it might make easier for deadlock detection, but not so sure right now cos we're already changing things to avoid thread ownership of locks.
>
> 2. Could lock striping become lock pooling with a simple object pool based on a Semaphore? In theory, we'd avoid the current issue with lock striping where two diff locks hash to the same segment and we have deadlocks. We could use, as the current lock striping logic does, the concurrency level to decide the number of semaphore permits.

Concurrency level -> number of permits ?
I don't get that, the way I'm reading it, it sounds like the more
efficient version would be to remove the semaphore ;)

>
> I'll prototype this on the side and see if I can make such conversion and see if it brings any benefits… :)
>
> In the mean time, if you have any feedback to provide, it'd be appreciated.
>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev