Bruce Momjian wrote:
>
> The problem with this patch is that it doesn't always lock the tables in
> the order supplied by the user, leading to possible deadlock. My guess
> is that you need to try locking A, B, C and if B hangs, I think you need
> to sleep on B, and when you get it, release the lock on B and try A, B,
> C again. I know this is a pain and could fail multiple times, but I
> think we have to do it this ay.
>
Deadlocks are not possible with this patch. The four conditions needed
for deadlock are (according to Operating Systems: Internals and Design
Principles, 4th Ed. by W. Stallings):
1. Mutual exclusion: Only one process may use a resource at a time.
2. Hold and wait: A process may hold allocated resources while awaiting
assignment of others.
3. No preemption: No resources can be forcibly removed from a process
holding it.
4. Circular wait: A closed chain of processes exists, such that each
process holds at least one resource needed by the next process in the
chain.
For deadlock prevention one needs only to prevent the existence of
at least one of the four conditions.
The patch code never holds any of requested locks, while waiting for a
locked relation to become free. If a lock on all tables in the lock list
cannot be acquired at once, it backs off and releases all locks.
Stallings writes about preventing condition 3: "This condition can be
prevented in several ways. [. . .] [One way is to require that,] if a
process holding certain resources is denied a further request, that
process must release its original resources and, if necessary, request
them again together with the additional resources."
This is exactly what the patch does. Observe that if one lock is not
available, the patch releases all locks so far acquired, and then
acquires
the locks again. Hence, condition 3 is prevented, and so deadlock is
prevented.
Neil
p.s. Is this mailing list always this slow?
--
Neil Padgett
Red Hat Canada Ltd. E-Mail: npadgett@redhat.com
2323 Yonge Street, Suite #300,
Toronto, ON M4P 2C9
