高级操作系统讲义.ppt

4、死锁的避免 死锁避免在分布式系统中从来都不采用。 既然在单处理机系统中都不采用死锁避免机制，那么在更复杂的分布式系统中我们又何必采用呢？ 该方法的问题在于银行家算法和类似算法需要（事先）知道每个进程最终到底需要多少资源。而这样的信息即使有也非常的少。 因此关于分布式系统中的死锁问题的讨论将只集中于两种技术：死锁检测和死锁预防。 * 2.5.1 分布式死锁检测 在一些分布式系统中原子事务的提出使得在死锁可以得到解决。 在一般操作系统中，在检测到死锁后，解决的方法是中止一个或几个进程，但这必然会使一些用户感到不满。 在基于原子事务的系统中检测到死锁后，解决方法是中止掉一个或几个事务。由于事务允许出现中止，不会导致用户不满，也不会导致系统出现其他后果，例如数据不一致等等。 * 当一个事务因为产生死锁而被中止的时候， 首先让系统恢复到事务开始前的状态，然后事务可以从这一点重新开始。 若运气好，事务在第二次执行时就能成功完成。 使用事务与不使用事务的差别在于使用事务时中止一个事务的后果要比不使用事务时终止一个进程的后果小的多。 * 1）集中式的死锁检测 集中式的死锁检测算法： 每一台机器都有一个资源图以描述自己所拥有的进程和资源；一台中心机器即协调者拥有整个系统（所有资源图的集合）的资源图；当协调者检测到了环路时它就中止一个进程以解决死锁。 * 全局资源图信息的维护 在分布式系统中需要精确维护全局资源图。 由于每台机器的资源图中只包含它自己的进程和资源。 所以，需要适当的方法维护全局资源图信息。 方法1：每当资源图中加入或删除一条弧时，相应的消息就发送给协调者以便更新。 方法2：每个进程周期性的把从上次更新后新添加的和删除的弧的列表发送给协调者。 这种方法比第一种方法发送的消息要少。 方法3：协调者在需要的时候主动去请求信息。 * 反例 不幸的是上述方法的效果都不太好。例如有这样一种系统 A和B运行在机器0上，C运行在机器1上。 共有三种资源S，R和T。 如图，一开始A拥有S并想请求R，但B正在使用R；C拥有T并想请求S。 * 资源使用“方框”表示 进程使用“圆圈”表示 从资源到进程的箭头表示“进程拥有资源” 从进程到资源的箭头表示“进程请求资源” 反例（cont’d） 协调者看到的情况如图c所示。 这种情况是不会产生死锁的。 * 反例（cont’d） 过一段时间后，B释放R并请求T，这是一个完全合法的安全操作。 机器0向协调者发送一条消息声明它释放R 机器1向协调者发送了一条消息声明进程B正在等待它的资源T。 不幸的是，机器1的消息首先到达，这导致协调者生成了一幅如图d所示的资源图。 * 集中式死锁检测中的假死锁问题 根据上图中的信息，协调者将错误的得出死锁存在的结论，并中止某个进程。 这种情况称为假死锁。 由于信息的延迟，使得分布式系统中的许多死锁算法产生了类似的假死锁问题。 * 解决假死锁问题 一种可能的解决方法是使用lamport算法以提供全局时间。 既然机器1发送到协调者的消息是由机器0的请求发引起的，那么，机器1发给协调者消息的时间戳就应该晚于机器0发送到协调者消息的时间戳。 当协调者收到了从机器1发来的有导致死锁嫌疑的消息后，给每台机器发送一条消息 “我刚刚收到一条会导致死锁的消息，带有时间戳T，若有任何小于T的消息要发给我，请立即发送。” * 解决假死锁问题（cont’d） 当每台机器或肯定或否定的响应之后，协调者就会看到从R到B的弧已经消失了，因此系统仍然是安全的。 尽管这种方法消除了假死锁，但它需要全局时间，而且开销很大。 * 2）分布式的死锁检测 Chandy-Misra-Haas算法（Chandy等，1983）允许进程一次请求多个资源（如锁）而不是一次一个。 通过允许多个请求同时进行使得事务的增长阶段可以加速。 但使得一个进程可以同时等待两个或多个进程。 * 资源图 下图是一种改进的资源图，图中只给出进程。 每条弧穿过一个资源，为简单起见从图中删除了资源 连接机器的弧使得寻找环路更加困难。 可以看到 机器1上的进程3正在等待两个资源，一个由进程4占有，一个由进程5占有。 一些进程正在等待本地资源，例如进程1。 一些进程，如进程2在等待其他机器上的资源。 * Chandy-Misra-Haas算法 当某个进程等待资源时，例如P0等待P1，将调用Chandy-Misra-Haas算法。 等待者进程生成一个探测消息并发送给占用资源的进程。 消息由三元组构成：被阻塞的进程，发送消息的进程，接受消息的进程。 由P0到P1的初始消息包含三元组（0，0，1）。 * （0,0,1） Chandy-Misra-Haas算法（cont’d） 消息到达后，接收者检查以确认它自己是否也在等待其他进程