Greedy locks
From Tim Eck:
The rationale behind greedy locks is to optimize the case where locks are used more frequently in one node (versus across the whole cluster). If a particular lock is contended only within some particular VM, the management of that lock can be done locally (as opposed to going the L2 to process each lock request). The default behavior for the L2's lock manager is to always cede control of the lock to the requesting client (ie. always award the lock "greedily").
The current policy (always awards greedy) is probably non-optimal when locks are really contended frequently between nodes (although I don't know if anyone has any hard data on that though). A better policy could be done with some sort of heuristic, or maybe configured per lock somehow.
From Saravanan Subbiah:
Greedy locks are lock given out by the server to the client, to be managed locally by the client. Then the client could decide who to give the lock to. This means that when multiple threads from a single VM or even a single thread in a VM is needing the lock repeatedly then it is handled with in the client without a round trip to the server. Hence the improvement in performance.
When a client holds a greedy lock and another client wants the same lock, the server does a recall to the client holding the greedy lock and the client pushes all the state of that lock to the server and the lock loses its greediness.
The server will not give out a greedy lock if it finds that there are lock requests from two different VMs for the same lock. This is good in most cases, but when there are multiple requests, say 2 from 1 VM and 2 from another VM, all four lock requests have to go to the server. One of the ideas that has been floating around is that if we have a lease time for greedy locks, we could reduce this to 2 round trips to the server instead of 4.
Altruistic locks
From Saravanan Subbiah:
Altruistic locks are non-greedy locks where the server manages the lock state. Which means every lock request and unlock request needs to go to the server and the server decides who to give the lock to. This is highly unoptimized because even if two threads from the same VM or the same thread in 1 VM needs the lock more than once, then it has to request the server and the server has to respond to it. So basically the thread waits for the round trip time. This is why you see a great degradation in performance when you enable this behavior in the server. This used to be the default behavior before greedy locks were implemented. The name is probably a misnomer and I take the blame for it.
Lock order
From Saravanan Subbiah:
Within a VM, lock order (requesting the same lock) is maintained when it is greedy, ie. first come first served. The server also does that, first come first served, but due to network latency one could get a lock before another request which was made in another node if you graphed it in absolute time scale. But thats just the way it is and I don't think that would cause any noticeable issue.
When the server gets a request for a greedy lock, it does a lock recall to the client, once the recall reaches the client, the client doesn't give out the lock to anyone. It pushes the state to the server, after the last holder releases the lock and then the server gives out the lock in FIFO manner.
