[infinispan-dev] Order of locking in optimistic tx cache

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Order of locking in optimistic tx cache

Radim Vansa
Hi Pedro,

I have a looong open JIRA [1] and so I've tried to look into current
ordering of locks. And I've noticed that we don't sort the keys anymore
but have a short 'big lock' [2] - I don't fully understand it, though.
What happens if T1 has A locked and T2 tries to lock A and B? Is T2
allowed to acquire lock on B and waits for A? Are the locks 'fair' and
the synchronized block introduces an ordering on the lock requests?

Thanks

Radim

[1] https://issues.jboss.org/browse/ISPN-2491

[2]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/concurrent/locks/impl/DefaultLockManager.java#L115

--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Order of locking in optimistic tx cache

Pedro Ruivo-2
Hi,

On 29-01-2018 17:42, Radim Vansa wrote:
> Hi Pedro,
>
> I have a looong open JIRA [1] and so I've tried to look into current
> ordering of locks. And I've noticed that we don't sort the keys anymore
> but have a short 'big lock' [2] - I don't fully understand it, though.
> What happens if T1 has A locked and T2 tries to lock A and B? Is T2
> allowed to acquire lock on B and waits for A?

T2 is allowed to acquire B but has to wait for T1 until it is ready to
proceed.

 > Are the locks 'fair' and the synchronized block introduces an
ordering on the lock requests?

The main reason of the block is to avoid deadlocks. Using your example,
the thread handling T2 won't block for A to be available and continues
trying to acquire the remaining lock.

Also, it has the benefit of ordering contented transactions and provides
fairness

Pedro
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev