📌  相关文章
📜  DBMS-死锁

📅  最后修改于: 2021-01-11 06:22:48             🧑  作者: Mango

在多进程系统中，死锁是在共享资源环境中出现的一种不希望的情况，在该环境中，一个进程无限期地等待另一个进程持有的资源。

例如，假设一组交易{T 0 ，T 1 ，T 2 ，…，T n }。 T 0需要资源X才能完成其任务。资源X由T 1保持，并且T 1正在等待资源Y，该资源Y由T 2保持。 T 2正在等待资源Z，该资源Z由T 0保持。因此，所有进程都彼此等待释放资源。在这种情况下，所有流程都无法完成其任务。这种情况称为死锁。

死锁对系统而言并不健康。如果系统陷入死锁，则死锁中涉及的事务将被回滚或重新启动。

防止死锁

为了防止系统中出现任何死锁情况，DBMS会积极检查将要执行事务的所有操作。 DBMS检查操作并分析它们是否会造成死锁情况。如果发现可能发生死锁情况，则永远不允许执行该事务。

有些死锁预防方案使用事务的时间戳排序机制来预先确定死锁情况。

等待死计划

在此方案中，如果事务请求锁定已由另一事务以冲突锁持有的资源(数据项)，则可能会出现两种可能性之一-

  • 如果TS(T I) j)的-也就是T I，这是请求冲突的锁，比T J旧的-则T i被允许等待直到数据项是可用的。

  • 如果TS(T i )> TS(t j )-即T i比T j-年轻，则T i死亡。 T i稍后以随机延迟但具有相同的时间戳重新启动。

该方案允许较旧的事务等待，但杀死较年轻的事务。

伤口等待方案

在这种方案中，如果一个事务请求锁定某个资源(数据项)，而该资源(数据项)已经被某个其他事务以冲突的锁定方式持有，则两种可能性之一可能会发生-

  • 如果TS(T i )j )，则T i迫使T j回滚-即T i伤口T j 。 T j稍后以随机延迟但具有相同的时间戳重新启动。

  • 如果TS(T i )> TS(T j )，则T i被迫等待直到资源可用。

该方案，允许年轻事务等待；但是，当较旧的交易请求较年轻的交易时，较旧的交易会迫使较年轻的交易中止并释放该项目。

在这两种情况下，稍后进入系统的事务都会中止。

避免死锁

中止交易并非总是可行的方法。相反，可以使用避免死锁机制预先检测任何死锁情况。可以使用诸如“等待图”之类的方法，但它们仅适用于事务轻量级且资源实例较少的系统。在庞大的系统中，防死锁技术可能会很好地起作用。

等待图

这是一种简单的方法，可以用来跟踪是否可能出现死锁情况。对于每个进入系统的交易，都会创建一个节点。当事务T i请求锁定某个项目(例如X)时，该事务由其他事务T j持有，则从T i到T j会创建有向边。如果T j释放了项X，则它们之间的边会掉落，而T i将锁定数据项。

系统为等待其他交易持有的某些数据项的每个事务维护此等待图。系统会不断检查图表中是否有任何循环。

等待图

在这里，我们可以使用以下两种方法中的任何一种-

  • 首先，不允许对已被另一笔交易锁定的商品提出任何要求。这并不总是可行的，并且可能导致饥饿，在这种情况下，事务无限期地等待数据项，并且永远无法获取它。

  • 第二种选择是回滚事务之一。回滚较年轻的交易并不总是可行的，因为它可能比较早的交易重要。借助某些相关算法，选择了要中止的事务。此事务称为受害者，此过程称为受害者选择。