未验证 提交 a76ae7a6 编写于 作者: L liu-jianhao 提交者: GitHub

Update README.md

上级 e5009a99
......@@ -15,6 +15,11 @@ LM的基本思想是它维护一个关于活动事务当前持有的锁的内部
这样就保证了冲突可串行化,但是不能保证不会发生死锁,所以我门采用下面的方法来预防死锁。
### Strict Two-phase locking - S2PL
在2PL的基础上,还要求事务持有的所有排他锁必须在事务提交后方可释放。
这个要求保证未提交事务所写的任何数据在该事务提交之前均以排它锁方式加锁,防止其他事务读这些数据。
### wait-die
Lock Manager 将实施WAIT-DIE策略以预防死锁
+ 该方案是基于非剥夺方法。当进程Pi请求的资源正被进程Pj占有时,只有当Pi的时间戳比进程Pj的时间戳小时,
......@@ -22,3 +27,26 @@ Lock Manager 将实施WAIT-DIE策略以预防死锁
+ 一个进程死亡后会释放他所占用的所有资源。在这里假定死亡的进程将带着同样的时间戳重新运行。
+ 由于具有较小时间戳的进程才等待具有较大时间戳的进程,因此很显然死锁不会发生。当进程在等待特定的资源时,不会释放资源。
+ 一旦一个进程释放一个资源,与这个资源相联系的等待队列中的一个进程将被激活。
### Lock Manager
锁管理器可以实现为一个过程,它从事务接受消息并反馈消息。锁管理器过程针对锁请求消息返回授予锁消息,或者要求事务回滚的消息。
解锁消息只需要得到一个确认回答,但可能引发为其他等待事务的授予锁消息。
锁管理器为目前已加锁的每个数据项维护一个链表,每一个请求为链表中一条记录,按请求到达的顺序排序。
它使用一个以数据项名称为索引的散列表来查找链表中的数据项,叫锁表。
上图包含五个不同数据项的锁。已授予锁的事务用深色阴影方块表示,等待授予锁的事务用浅色方块。
除了图上看到的,锁表还应当维护一个基于事务表示符的索引,这样它可以有效地确定给定事务持有的锁集。
锁管理器处理请求:
+ 当一条请求消息到达时,如果相应数据项的链表存在,在该链表末尾增加一个记录;否则,新建一个包含该请求记录的链表。
+ 收到一个事务的解锁消息是,它将与该事务相对应的数据项链表中的记录删除,然后检查随后的记录,如果有,检查该请求能否被授权
+ 如果一个事务中止,锁管理器删除该事务产生的正在等待加锁的所有请求。
这个算法保证了锁请求无饿死现象,因为在先前接受到的请求正在等待加锁时,后来者不可能获得授权。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册