问更新锁如何防止常见形式的死锁？

EN

Server联机丛书说UPDATE锁可以防止一种常见的死锁形式：

更新锁 Update (U)锁防止常见的死锁形式。

它们如何防止一种常见的僵局？

我这么说是什么意思？

一种常见的死锁形式是两个进程试图从共享(S)锁(即读锁)升级到独占(X)锁时：

Process A                       Process B
========================        ========================
Acquire Shared lock
                                Acquire Shared lock
Attempt to escalate to X
Escalation waits on B 
                                Attempt to escalate to X
                                Escalation waits on A

死锁.这两个进程都在等待对方。

这一点在“巴塞尔公约”中作了解释：

典型的更新模式包括读取记录的事务，获取资源(页或行)上的共享(S)锁，然后修改行，这需要将锁转换为独占(X)锁。如果两个事务获取资源上的共享模式锁，然后尝试并发更新数据，则有一个事务尝试将锁转换为独占(X)锁。共享模式到独占锁转换必须等待，因为一个事务的独占锁与另一个事务的共享模式锁不兼容；出现锁等待。第二个事务试图获取用于更新的独占(X)锁。因为两个事务都在转换为独占(X)锁，而且它们都在等待另一个事务释放其共享模式锁，因此会出现死锁。

使用更新锁来防止死锁。

联机丛书没有解释update (U)锁如何防止这种常见的死锁形式，他们只说：

为了避免这个潜在的死锁问题，使用update (U)锁。一次只有一个事务可以获得资源的update (U)锁。如果事务修改了资源，则update (U)锁将转换为独占(X)锁。否则，锁将转换为共享模式锁.

描述不完整。如果您查看短语“一次只有一个事务可以获得对资源的更新(U)锁”。这与独占(X)锁没有什么不同--只有一个事务可以在同一时间获得对资源的排他(X)锁。但无论如何，让我们试着解决这个问题：

首先，我们假设的是一个正常的更新过程：

• 获取共享(S)锁
• 试图升级到更新(U)锁
• 执行更新
• 需要改变价值，升级为独占(X)锁
• 升级为排他(X)锁
• 执行更新
• 释放所有锁

所以现在添加第二个进程

Process A                       Process B
========================        ========================
Acquire Shared lock
                                Acquire Shared lock
Attempt to escalate to U
Escalation waits on B 
                                Attempt to escalate to U
                                Escalation waits on A

死锁.这两个进程都在等待对方。

更新(U)锁如何防止常见形式的死锁？