软件技术基础报告文档格式.docx

软件技术基础报告文档格式.docx

《软件技术基础报告文档格式.docx》由会员分享，可在线阅读，更多相关《软件技术基础报告文档格式.docx（6页珍藏版）》请在冰点文库上搜索。

李骏扬

二零一三年9月10日

目录

1.研究问题的起因-------------------------------------3

2.资源死锁的基本概念----------------------------------4

3.程序模拟哲学家进餐问题------------------------------5

4.资源死锁的解决方法----------------------------------7

5.总结------------------------------------------------10

1.研究问题的起因：

在上《软件技术基础》这门课的时候，老师讲了许多操作系统的知识，其中最让我感兴趣的就是操作系统的资源死锁问题。

这也是每个程序员最头痛的问题，资源死锁并不是资源不够，而是产生了冲突从而造成死锁，资源死锁可以简单的用哲学家就餐问题来概括：

假设有五位哲学家围坐在一张圆形餐桌旁，做以下两件事情之一：

吃饭，或者思考。

吃东西的时候，他们就停止思考，思考的时候也停止吃东西。

餐桌中间有一大碗意大利面，每两个哲学家之间有一只餐叉。

因为用一只餐叉很难吃到意大利面，所以假设哲学家必须用两只餐叉吃东西。

他们只能使用自己左右手边的那两只餐叉。

哲学家从来不交谈，这就很危险，可能产生死锁，每个哲学家都拿着左手的餐叉，永远都在等右边的餐叉（或者相反）。

老师在上课的时候给我们用线程演示了哲学家就餐问题（用线程模拟进程），发现在没有外界干扰的情况之下让哲学家自由地拿叉子，一开始还有一两个人可以吃得到面，时间一长，发现最后大家饿着肚子都握着左手的叉子在等右边的叉子。

放到进程与进程之间也就是说：

大家都站着一部分资源，然后等着另外一部分从而什么都不干。

这也就让用户非常不爽，资源你也站了，可是我要你做的事情你没做。

那么这个问题要如何解决呢？

2.资源死锁的基本概念：

死锁是指多个进程因竞争系统资源或相互通信而造成的一种僵局，若无外力作用，这些进程都将永远不能向前推进。

如：

（设S1,S2的初值为1,1）

进程1进程2

wait（S1）;

wait（S2）;

使用资源；

signal（S1）;

signal（S2）;

日常生活中的死锁例：

假设一条河上有一座独木桥，若桥两端的人相向而行……

死锁产生的原因是：

竞争资源：

多个进程竞争资源，而资源又不能同时满足其需求。

进程推进顺序不当：

进程申请资源和释放资源的顺序不当。

2.程序模拟哲学家进餐问题：

现在我们来用c++程序模拟一次哲学家进餐的问题，先看看理想的情况：

非常的理想，大家轮流总而言之都吃到面了（假设用餐一次就吃完了），而老师上课给大家演示的似乎是一直在吃，原理也一样。

大家都吃到面只不过是运气好没发生死锁，多吃几次总会发生死锁。

那么运气不好的情况呢？

才3轮就已经死锁了，大家都在等待，桌子上已经没有了叉子，但是大家都饿着肚子。

3.资源死锁的解决方法：

首先思考，5个哲学家为什么会都吃不上面？

因为大家都占着一只叉子而且在等另一只叉子。

有的同学就在提出：

如果我让哲学家用餐时间长一点呢？

老师的回答是：

迟早还是会发生死锁，只是晚一点而已，治标不治本。

有的同学又说：

那我多给一只叉子不就好了？

这个问题就很有意思：

可能还是会发生死锁，也可能不会。

反正大家都知道如果5个哲学家给10只叉子，大家各吃各的那么绝对不会发生死锁。

我能多给一只为什么不多给5只？

这就绕开了我们要探讨的目的：

资源是有限的。

我们是要让资源尽可能的得到利用，而不是说我无限给你资源你去把问题解决。

如果是这样的话，那么一台计算机运行一个进程就好了，绝对没人和你抢资源。

以下给出几种能够解决问题的方法：

1.服务生解法

一个简单的解法是引入一个餐厅服务生，哲学家必须经过他的允许才能拿起餐叉。

因为服务生知道哪只餐叉正在使用，所以他能够作出判断避免死锁。

为了演示这种解法，假设哲学家依次标号为A至E。

如果A和C在吃东西，则有四只餐叉在使用中。

B坐在A和C之间，所以两只餐叉都无法使用，而D和E之间有一只空余的餐叉。

假设这时D想要吃东西。

如果他拿起了第五只餐叉，就有可能发生死锁。

相反，如果他征求服务生同意，服务生会让他等待。

这样，我们就能保证下次当两把餐叉空余出来时，一定有一位哲学家可以成功的得到一对餐叉，从而避免了死锁。

这种方法通俗的说就是引入了第三者：

服务生程序来调控资源。

2.资源分级解法

另一个简单的解法是为资源（这里是餐叉）分配一个偏序或者分级的关系，并约定所有资源都按照这种顺序获取，按相反顺序释放，而且保证不会有两个无关资源同时被同一项工作所需要。

在哲学家就餐问题中，资源（餐叉）按照某种规则编号为1至5，每一个工作单元（哲学家）总是先拿起左右两边编号较低的餐叉，再拿编号较高的。

用完餐叉后，他总是先放下编号较高的餐叉，再放下编号较低的。

在这种情况下，当四位哲学家同时拿起他们手边编号较低的餐叉时，只有编号最高的餐叉留在桌上，从而第五位哲学家就不能使用任何一只餐叉了。

而且，只有一位哲学家能使用最高编号的餐叉，所以他能使用两只餐叉用餐。

当他吃完后，他会先放下编号最高的餐叉，再放下编号较低的餐叉，从而让另一位哲学家拿起后边的这只开始吃东西。

尽管资源分级能避免死锁，但这种策略并不总是实用的，特别是当所需资源的列表并不是事先知道的时候。

例如，假设一个工作单元拿着资源3和5，并决定需要资源2，则必须先要释放5，之后释放3，才能得到2，之后必须重新按顺序获取3和5。

对需要访问大量数据库记录的计算机程序来说，如果需要先释放高编号的记录才能访问新的记录，那么运行效率就不会高，因此这种方法在这里并不实用，因为我不知道我什么时候需要资源。

上课时老师是这么解决这个问题的：

很简单，当拿不到另外一只叉子时，就放下手中的叉子。

果然，经过改良以后的程序总是能保持2个哲学家同时吃饭。

最大化的利用了资源，而且没有出现死锁。

其实老师的方法应该是静态资源分配法，要求进程一次申请它所需的全部资源，若有足够的资源则分配给进程，否则不分配资源，进程等待。

每个进程在请求新资源之前必须释放其已占有的资源。

可能在进程间使用的时候会有些资源利用率低的问题，但是简单安全，易于运行。

总结

资源死锁有许多的解决方法，有的简单有的复杂，但是各有各的特点。

除非真的给5个哲学家10只叉子，让大家同时吃面。

否则这个问题怎么样也没办法圆满解决，只有最好的解决方案而已，对于不同的情况使用不同的方案。

《软件技术基础》这门课转眼就结束了，我收获很大，至少我明白了操作系统的一些以前不懂的问题。

关于哲学家就餐的问题，我也是听老师讲了一部分，自己又上网找了一些资料，了解了一下，整合了一些自己的看法写出了这篇报告，可能有一些错误也在所难免。

我觉得更重要的是学会了思考问题解决问题的方法，希望这些方法能在以后的学习生活中用到。