第四章-分布式资源管理.pptVIP

  1. 1、本文档共51页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
第四章-分布式资源管理

* * 不同的数据存储管理模式有不同的特点,适用的范围也不同,设计者应根据应用系统的特点选择适用的模式。 关系数据库管理系统(RDBMS):关系数据库管理系统建立在关系理论的基础上,它使用若干表格来管理数据。通常根据规范化的要求,可对表格和它们的各栏重新组织,以减少数据冗余,保证修改一致性数据不致出错。规范化的要求用“范式”来定义。 具体参见张海藩书P252 * 面向对象的数据库管理系统以两种方法实现: 扩充的RDBMS主要对RDBMS扩充了抽象数据类型和继承性,再加上一些一般用途的操作来创建和操纵类与对象。扩充的OOPL对面向对象程序设计语言嵌入了在数据库中长期管理存储对象的语法和功能。这样,可以统一管理程序中的数据结构和存储的数据结构,为用户提供了一个统一视图,无需在它们之间做数据转换。 * 4.3.3 利用时间戳预防死锁方法 预防死锁即破坏导致死锁成立的四个必要条件之一入手。 四个必要条件: 互斥 请求与保持 不剥夺 环路等待 我们可以通过抢占资源(如果必要)来破坏循环等待条件。 为了控制抢占,我们给每个进程赋一个唯一的优先数,这些优先数用以决定进程pi是否等待进程pj。例如,如果pi的优先数高于pj的优先数,我们可以让pi等待pj,否则pi被撤离。这种方法能防止死锁,因为对于等待图中的每一条边(pi, pj),pi的优先数高于pj的优先数,因此也就不存在循环等待现象。 可能会发生饥饿现象? 提出了使用时间戳作为优先数的方法。 对系统中的每一进程,当创建它时,就赋给它一个时间戳, * * ⑴ 等死(wait-die)方法:是一种基于非抢占性技术的方法。当进程申请当前己由pj占有的资源时,仅当pi的时间戳小于pj的时间戳(即pi比pj年长)时,让pi等待,否则pi被撤离(死去)。例如,假定进程p1,p2和p3分别有时间戳5,10和15,若p1申请已由p2占有的资源,p1就等待;如果p3申请已由p2占有的资源,p3就被撤离。 利用时间戳预防死锁的两种方法是: * ⑵ 因伤等待(wound-wait):是一种基于抢占性技术的方法。而且与上述方法对应。当pi申请当前已由pj占有的资源时,如果pi的时间戳大于pj的时间戳(即pi比pj年轻)时.让pi等待,否则pj被撤离(即pj被pi致伤),pi占有资源。再考虑前面的例子,如果p1申请已由p2占有的资源,那么该资源从p2手中抢占,而且p2被撤离;如果p3申请已由p2占有的资源,则p3就等待。 * 这两种方案都可以避免饥饿现象发生,只要对被撤离的进程不再赋以新的时间戳,因为时间戳总是递增的,因此,被撤离的进程最终将具有最小的时间戳,因此它将不会再次被撤离。但这两种方案是有差别的: ⑴在“等死”方案中,年长的进程必须等待年轻的进程释放它的资源,因此进程越“年长”,它就越容易引起等待。与此相反,在“因伤等待”方案中,年长的进程决不会等待年轻的进程。 * ⑵在“等死”方案中,如果进程pi因为申请已由进程pj占领的资源而被撤离和死掉,那么当它再次激活时,它又可能再次发出相同的申请,此时,若资源仍由pj占有,那么,pi将再次“死’’掉。因此在得到所需要的资源之前。pi可能被撤离若干次。但在“因伤等待”方案中,进程pi因为pj申请已由它所占有的资源而被撤离和致伤,当pi再次激话并申请正由pj占有的资源时,pi就等待。因此,在“因伤等待”方案中撤离的次数较少。 * 死锁预防算法甚至在不发生死锁时也可能抢占资源。 死锁检测算法 构造一等待图来描述资源分配状态。因为我们假定每类资源只有单个例示,因此,等待图中的环路就表示死锁发生。 如何管理等待图? 要求每一场点管理一个局部等待图。图中的结点对应所有这样的进程(本地及远程的),这些进程当前正占有或者正在申请局部于该场点的任何资源。例如,图4.6中的系统由两个场点组成,每个场点都管理它的局部等待图。注意进程p2和p3出现在两个图中,表示它们在两个场点中申请资源。 4.3.4 死锁检测方法 * 图4.6局部等待图和全局等待图 * 显然,如果任何局部等待图中存在环路,则表明发生了死锁。但任何局部等待图中不出现环路并不意味不存在死锁。 例如,考虑图4.6中的情况,其中每个局部等待图中均无环路,但该系统却存在死锁,因为在它的所有局部等待图之并图中存在环路。图4.7中的等待图就是图4.6中两个(局部)等待图之并,它的确含有环路,这隐含该系统存在死锁。 有许多不同的方法构造分布式系统中的等待图,几个常用的方法介绍如下: * 4.3.5 集中式死锁检测方式 采用集

文档评论(0)

baoyue + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档