• 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

Oo目录的第二个单元总结了第一部分同步块的构造和选择,第二部分调度器设计,第三部分第三作业架构分析,第四部分自我分析bug策略,第五部分思想和经验。

oo第二单元总结

PART 1 同步块构造与选择

在这一单元,我们进入了多线程的世界,最重要的概念是同步锁。在本单元中,我们在作业中选择了同步锁。一开始我尝试在电梯的属性里设置同步锁,这个尝试让我连续失败了四次。所以我借用了实验三的代码框架,简单的给传送带的所有方法设置了同步锁。后来才反应过来。我还应该锁定打印机(输出类)以防止输出序列问题。同时,每次设置发生变化时都要notifyAll()以保证整体的流畅运行。

PART 2 调度器设计

在这个实验中,我的调度器的主要内容是将输入传送带waitQueue中的任务分配给应该执行任务的处理传送带。前两个实验很简单,按照任务的楼层或楼层分配到相应的队列中即可。但是在第三个实验中,因为斜请求的存在,我们必须能够拆分请求,所以我没有构造严格意义上的最短路径算法。相反,创建了一个新的find函数来查询应该分配的队列。同时在请求(人)中加入中转标志,进行动态规划调度,即需要转移的任务多次进入调度器,调度完成。

PART 3 三次作业架构分析

三种操作结构如下

第五项任务

cx5vk1qkdhz6164.png

第六项任务

1io323nzty56165.png

第七项任务

hypuujuqtsx6166.png

协作图

4jkrkshju0a6167.png

三个作业中的第五个作业采用的是单任务调度模式,是四五次重构后寻求稳定的无奈妥协。第六次任务开始时,我采用了look策略和电梯自由竞争3360,即电梯内没有请求时,以电梯外最远的等待请求为目标任务。相反,将电梯内最远的任务作为目标任务,在每层楼和人进出时刷新。实现相对简单,但可能不是最佳的。在第七个任务中,我采用了斜向请求的动态规划,并在定制水平电梯开关门的基础上,设置了Horizon信息类,便于处理队列查询,同时避免了处理队列与电梯之间的过度耦合。

就可伸缩性而言,从第五个作业到第六个作业的理想迭代应该是从电梯父类派生出水平电梯和垂直电梯。但是,我选择了统一使用电梯类。根据不同的类型,我采用了两种完全不同的任务处理策略来方便电梯流程的设置。对于扩展,我可以选择继承电梯类或者添加新的处理逻辑,根据电梯的各个运行参数自定义相关属性。而地平线等特殊信息类的出现,可以避免在处理队列中绑定太多电梯造成的逻辑混乱。以后也可以用。

PART 4 自我分析bug策略

以下主要bug:出现在本单元的三个操作中。

第五个作业3360以错误的顺序输出电梯。

第五次赋值,由于前三四次架构崩溃,可能无法实现捎带或者可能存在ctle。后来又重建了。我的电梯虽然不能实现捎带,但是解决了ctle问题,我也没有注意到有些输出时间戳不增加的问题。后来被舍友提醒需要注意这个现象后,我就锁定了打印机的静态方法。

第六份工作,3360,电梯到地面。

在第六次赋值开始的时候,本地和强测试并没有出现奇怪的输出错误,但是后来我在检查我的代码的时候发现,在输出arrive之前判断楼层移动的时候,可能会有一个潜在的风险,就是目标楼层和这个楼层是一样的但是移动了,也就是可能会有人接到一个从8楼的电梯从1楼到2楼的作业。

务,部分情况下电梯掉头不及时,导致了电梯去0层虚空接人的bug,修改增加判定目标楼层是否与本楼层相同即解决了这个问题.

第七次作业:关不上门的电梯

这次的bug尤其可恨,让我直接十个点全ctle,bug来源是因为waitQueue的来源不止只有input了,其他没做完的中转任务也会被扔回去,所以需要新增waitQueue的属性todo去结算waitQueue是否完成所有任务的输入,但我只顾改动了为传送带添加任务请求的函数,忘记改动取请求的,后者应该在本队列为空并且(当前队列没达到末尾或者仍有任务会增加到waitQueue时)进入等待,我的朋友yhy则是在由waitQueue输入完成通知其余处理队列上增加了一些细节修好了这个bug,可以说他的处理方法更加简洁
由于本人第二单元未进行hack,故不在此分析hack他人策略

PART 5 感想与体会

从层次化角度来看,这次我的代码我个人认为得益于生产者消费者模式,有了较好的层次,input对接waitQueue实现数据生产,scheduler实现调度,processingQueue进一步让电梯们自由竞争任务,最后电梯执行任务,大概是这样的设计,各层次分工明确,在正常运行时不会过分干涉.

从线程安全角度来看,本单元最开始因为线程不安全问题,我经历了四次痛苦的重构,这让我深切体会到线程安全的重要.可以说本单元作业最大的感想就是心累与恐惧,第五次作业的时候,我花了一整个清明假期,经历了四五遍重构以及找周围朋友求助还是没找到陷入ctle点的问题,(真的是接近完全重构了),我迫于无奈转向了单任务型电梯,得到了稳定,然而问题并没有完全得到解决,第六次作业迭代难度并不大,很感谢这次的命题让我有信心重新面对电梯这一单元的问题,在好友建议要在处理队列建立任务容器而不是在电梯反复操作之后我终于解决了以前的问题,顺利实现了捎带,真的感谢给我支持的几位朋友以及讨论区的几位大佬,第七次作业我最后还是对着ctle无能狂怒,但我不断分析查看终于解决了问题,最后还努力去帮助和我有同样问题的人,我想学习确实是个人的事情,但是通过大家的讨论与合作,我确实成长了不少.希望我能不断精进自己debug水平,提升自我

Link to comment
Share on other sites