软件构造Lab6总结

软件构造课真是一门好课（各种意义上）
Lab6是关于多线程应用知识的具体应用，首先给大家看看实验手册

这个实验除了实现要求的功能外，最重要的是尽可能高的提高吞吐率，吞吐率的具体计算方式是所有猴子通过桥的总时间除以猴子数量。在实验手册3.4的各项要求的情况下，猴子数量、猴子的各项参数，桥数量、桥长度都是有文件指定的，在参数都已经确定的情况下要提高吞吐率，核心是猴子如何选取一条路使得它能更快的走完。
我在读完手册时，第一反应是手册提供的策略2可能会比较有效率，于是把它作为我的第一个策略，但在实现之后，我突发奇想，如果一座桥上，速度为9的猴子走在最前面，之后是速度为8的、然后为7的、为6的等等等等，岂不是能充分利用这座桥达到最大的效率吗？
于是我提出了另一种策略：猴子选择同向的、桥上所有猴子的最小速度仍比自己大、但是差值最小的桥，如果没有合适的桥再选择空的桥，都没有那就不选，原地等待。 这样桥上的前一个猴子总比后一个猴子速度大，猴子可以井然有序的走过桥。
在解决了一些线程安全问题（桥的第一个板上有猴子就会等待，不往上走之类的）我终于实现了这个策略。但是测试的时候却让我大跌眼镜，吞吐率并没有我想的那么高，经过调试后发现，原因还是出在CPU进程调用的随机性的问题上，假设现在是程序刚运行，桥都是空的，第一时刻产生了5只猴子，速度有快有慢，因为桥都是空的，按照策略谁都能抢空的桥桥，但是如果慢的猴子先抢到桥，快的猴子按照策略就不得不放弃并寻找新的桥，甚至有可能抢不到桥而原地等待。也就是说从第一步开始这个策略就有问题。
经过我的思考，再优化方案有两个：一：做一个缓冲机制，猴子选定桥后向桥发出一个请求，桥总是同意速度最快的猴子的请求并拒绝其他猴子，被同意的可以上桥而被拒绝的重新选择。 不需要实际操作就知道效果是肯定立竿见影的，但这有点违反手册上说的“禁止上帝视角”的原则。二：妥协一下，猴子选不到最适合的桥或者空桥，那么可以选速度比自己低但低的最少的桥，但是也要有底线，速度差的太多就放弃不选原地等待
最后我选了第二个优化方案，吞吐率有明显的提升。