Re: Revised Patch to allow multiple table locks in "Unison"

Neil Padgett <npadgett@redhat.com> writes:
> the contenders for a lock both have to go through a spin lock. So, if we
> have the two "stuck" processes as in Tom's example, one will win at
> acquiring the spin lock and the other will have to wait. So, they become
> desynchronized, regardless of how many CPUs or what memory architecture
> you have.

No, actually the existence of the lockmanager mutex (spinlock) makes the
scenario I described *more* plausible.  Note that the scenario involves
a strict alternation of lockmanager operations by the two processes:

>> A possible interleaving of execution is: 1 acquires lock a, 2 acquires
>> b, 1 tries to acquire b and fails, 2 tries to acquire a and fails,
>> 1 releases a, 2 releases b, 1 acquires b, 2 acquires a, 1 tries to
>> acquire a and fails, etc etc.  It's implausible that this condition
>> would persist in perfect lockstep for very long on a uniprocessor
>> machine ... but not so implausible if you have dual CPUs, each running
>> one of the two processes at exactly the same speed.

Each process will be acquiring the lockmanager spinlock, doing a little
computation, releasing the spinlock, doing a little more computation
(in the LOCK statement code, not in the lockmanager), and then trying to
acquire the spinlock again.  When process 1 has the spinlock, process 2
will be waiting to acquire it.  As soon as 1 releases the spinlock, 2
will successfully acquire it --- so, quite plausibly, 1 will complete
its outside-the-lock-manager operations and be back waiting for the
spinlock by the time 2 releases it.  Even if 1 is a little slower than
that, it will probably manage to come along and retake the spinlock
before 2 does.  So the existence of the spinlock actually smooths out
any irregularities in elapsed time and helps to ensure the two processes
stay in sync.

The pattern of alternating between hard and conditional locks won't help
any either.  If, say, 1 gets a little ahead and arrives at the first
part of its cycle ("acquire lock a") before 2 has released lock a, guess
what --- it blocks until it can get a.  I think that could help
stabilize the loop too.

Long-term persistence of this pattern is somewhat less plausible on a
uniprocessor, but given the way our spinlocks work I don't think it's
completely out of the question either.

            regards, tom lane