• Welcome to the world's largest Chinese hacker forum

    Welcome to the world's largest Chinese hacker forum, our forum registration is open! You can now register for technical communication with us, this is a free and open to the world of the BBS, we founded the purpose for the study of network security, please don't release business of black/grey, or on the BBS posts, to seek help hacker if violations, we will permanently frozen your IP and account, thank you for your cooperation. Hacker attack and defense cracking or network Security

    business please click here: Creation Security  From CNHACKTEAM

Recommended Posts

第一次作业:

同步块设置与锁的选择:

第一个操作比较简单,需要实现一个垂直电梯调度问题。

我把电梯和输入请求当作线程,把请求队列当作中间的交互通道,把添加请求、获取请求等操作锁在请求队列里。这样就可以实现线程安全的交互。

调度器设置:

第一个作业的调度相对简单,因为只有从上到下的请求。我的调度器只是将输入线程中的请求分配给相应的电梯等待队列。

架构模式+UML图:

我考虑使用生产者-消费者模型,它可以为电梯和请求之间的交互建立一个框架。

为了避免电梯收到请求时轮询,我考虑在大楼的请求队列为空时休眠线程,在请求队列新增后唤醒。

UML图如下所示:

smucouzpaph2578.png

遇到的Bug:

第一次任务中使用了ALS策略,但在实施过程中并不是很合理。在接收主请求时,没有处理捎带,导致时间消耗太大。经过分析,决定改为look策略。

实际证明在随机数据的情况下,look策略比ALS更好,更符合常识。

发现别人的Bug的策略:

第一个作业的问题主要集中在锁的设置不应该导致死锁的情况,在随机数据的情况下应该检测到死锁。

然后就是线程不安全的情况,比如输出的时候没有使用线程安全的输出。这确实可以在本地测试,但是由于多线程的随机性,很难在评估机上重现。

第二次作业:

第二个作业和第一个作业相比没有大的变化,而且我把ALS改成look策略后的时间复杂度也很好,所以这个作业就直接放了。

主要是增加了水平电梯,但是圆形水平电梯和垂直电梯本质上没有太大区别。

调度器设置:

除了将垂直请求放入垂直电梯请求队列之外,还需要将水平请求放入水平电梯请求队列。

架构模式+UML图

该架构仍然使用消费者生产者架构。

UML图如下所示:

mknaxhua4i02579.png

与上次相比,增加了水平升降舵螺纹,其他部分变化不大。

遇到的Bug:

没有

发现别人Bug的策略:

随机测试(但似乎没有发现错误

第三次作业:

在前两次分配的基础上,第三次分配增加了不同建筑和楼层之间的请求,因此需要处理这些请求。

同步块设置以及锁的选择:

与第二次操作相比,同步块几乎没有变化。

但是对于锁,我最初锁定了RequestQueue中的所有操作,但是这将导致一个问题:

现在假设有两个电梯线程A\B使用同一个请求队列。

a . checkend()-notify all()-b . wake up()-b . checkend()-notify all()-a . wake up()-a . checkend()

就进入了这样的循环,直到这个电梯下一次有请求,就会有poll,导致一堆poll在强测中被扼杀。

所以最后我删除了getEnd等判断函数的锁,以免轮询。

架构模式+UML图:

总的来说,该架构仍然是生产者和消费者,但是由于请求是分段的,分段后的请求具有连续的顺序,因此添加了管道架构来处理分段的请求。

分段时,我选择了说明书中静态分配一台水平电梯的方法,这样一个请求最多可以分成三部分。

分段部分,我新开了一个Change类,目的是找换乘水平电梯楼层,方便办理。

然后,在最后,因为请求队列可以相互传输请求,所以终止条件应该是直到所有请求完成,而不是输入结束。

这里我用OS中信号量的概念来计数,处理的请求数只有达到输入请求数时才标记end。

UML图如下所示:

dactqfx1zh32580.png

遇到的Bug:

当多个电梯共享一个请求队列时,将会引起轮询。

发现别人Bug的策略:

我在测试中发现了自己的问题,就用hack自己的数据黑了别人。

在寻找轮询的过程中,除了思想内部的CPU使用情况,还可以输出。如果有很多重复输出,说明可能有轮询,这样定位也更方便,调试的时候可以更快。

心得体会:

总的来说,这个单元作业做的不错,但是第三次作业比较懒,没有考,导致了强考大送。

层次化设计:

学到了很多新的设计模式,可以用在很多地方,比如流水线,主从模式等等。

线程安全:

刚开始的时候,所有的操作都是被懒惰锁住的。虽然没有正确性的问题,但是在时间上的表现并不优秀,后期的第三个作业也导致了轮询,所以需要考虑锁的必要性。

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now