现在我们熟悉什么是两阶段锁定 (2-PL) 以及应遵循的基本规则,以确保可序列化。此外,我们遇到了 2-PL、级联中止和死锁的问题。现在,我们转向对 2-PL 所做的增强,它试图使协议几乎没有错误。简而言之,我们允许对 2-PL 进行一些修改以改进它。共有三类:
- 严格的 2-PL
- 严谨的2-PL
- 保守 2-PL
现在回想一下 Basic 2-PL 中遵循的规则,在此基础上我们进行了一些额外的修改。现在让我们看看有哪些修改以及它们解决了哪些缺点。
严格的 2-PL –
这就要求除了锁定为2相全排他(X)事务持有的锁被释放,直到事务提交后。
遵循严格的 2-PL 确保我们的日程安排是:
- 可恢复
- 无级联
因此,它使我们免于在 Basic 2-PL 中仍然存在的级联中止,而且保证严格的时间表,但仍然可能出现死锁!
严格的 2-PL –
这就要求除了锁定为2相全排他(X)和事务持有共享(S)锁被释放,直到事务提交后。
遵循严格的 2-PL 确保我们的日程安排是:
- 可恢复
- 无级联
因此,它使我们免于在 Basic 2-PL 中仍然存在的级联中止,而且保证严格的时间表,但仍然可能出现死锁!
请注意,严格 2-PL 和严格 2-PL 之间的区别在于严格的限制性更强,它需要在事务提交之前持有独占锁和共享锁,这使得严格 2-PL 的实现更容易。
保守党 2-PL –
AKA Static 2-PL ,该协议要求事务在事务开始执行之前通过预先声明其读取集和写入集来锁定其访问的所有项目。如果无法锁定所需的任何预先声明的项目,则事务不会锁定任何项目,而是等待所有项目都可用于锁定。
Conservative 2-PL 没有死锁,但它不能确保严格的时间表(更多关于这个在这里!)。但是,由于需要预先声明读集和写集,这在许多情况下是不可能的,因此在实践中很难使用。在实践中,最流行的 2-PL 变体是 Strict 2-PL。
下面的维恩图显示了严格和严格的时间表的分类。 Universe 表示可以序列化为 2-PL 的计划。现在如图所示,也可以从逻辑上得出结论,如果时间表是严格的,那么它就是严格的。我们也可以换一种方式思考,比如说我们对一个时间表进行了限制,使其变得严格,在限制列表中添加另一个使其变得严格。花点时间再次分析图表,你一定会明白的。
图像 –维恩图显示 2-PL 下的语言类别
现在,让我们看看下面的时间表,告诉我这个时间表是否可以使用 2-PL 锁定,如果是,请说明您的答案是如何以及属于哪个类别的 2-PL?
T1 | T2 | |
---|---|---|
1 | Read(A) | |
2 | Read(A) | |
3 | Read(B) | |
4 | Write(B) | |
5 | Commit | |
6 | Read(B) | |
7 | Write(B) | |
6 | Commit |
我建议您在查看解决方案之前先尝试一下。
是的,调度是冲突可序列化的,所以我们可以尝试实现 2-PL。所以,让我们试试……
解决方案:
T1 | T2 | |
---|---|---|
1 | Lock-S(A) | |
2 | Read(A) | |
3 | Lock-S(A) | |
4 | Read(A) | |
5 | Lock-X(B) | |
6 | Read(B) | |
7 | Write(B) | |
8 | Commit | |
9 | Unlock(A) | |
10 | Unlock(B) | |
11 | Lock-X(B) | |
12 | Read(B) | |
13 | Write(B) | |
14 | Commit | |
15 | Unlock(A) | |
16 | Unlock(B) |
现在,这是我选择在 A 和 B 上实现锁定的一种方式。您可以尝试不同的顺序,但请记住遵循 2-PL 协议。话虽如此,请注意我们的锁在提交操作后被释放,因此这满足严格的 2-PL 协议。
到现在为止,我想您一定已经知道如何区分 2-PL 的类型了。当考试中出现问题时,请记住理论,有时只是基于理论知识。接下来,我们将看一些保守 2-PL 的示例,以及它与上述两种类型的 2-PL 有何不同。是什么让它没有死锁,而且实现起来也如此困难。然后我们将结束2-PL的话题。很快我们将转向另一种基于锁的协议——基于图的协议。它们也非常有趣,并提供了一种独特的方法来处理死锁问题!所以我们将学习一种新型的锁定协议,这将结束GATE的基于锁定的协议的主题,直到快乐学习。
GATE相关问题:
门CS | IT 2004 |第 77 题