一.多线程电梯系列作业设计策略 1. 第一次作业——"FAFS傻瓜电梯" 第一次作业是先来先服务的"傻瓜电梯",我当时觉得这个设计未免太简单了,于是就在傻瓜电梯的基础上加上贪心算法,每次都执行电梯内外距离最近的请求(但是没有行进中的捎带).由于第一次没有限制CPU时间,而且我的wait--notify用得不太熟,因此就采取了暴力轮询的方式.我将我将调度器线程写在了main函数中(这是个很不好的设计,第三次作业中将其改进)作为一个线程,电梯作为一个线程,输入作为一个线…

OO第二次博客作业——电梯调度 前言 最近三周,OO课程进入多线程学习阶段,主要通过三次电梯调度作业来学习.从单部电梯的傻瓜式调度到有性能要求的调度到多部电梯的调度,难度逐渐提升,对同学们的要求逐渐变高,我们对线程的理解也逐渐加深.下面笔者将对三次作业分别进行总结. 一.单部多线程傻瓜调度(FAFS)电梯 说明:本次作业需要模拟一个多线程实时电梯系统,从标准输入中输入请求信息,程序进行接收和处理,模拟电梯运行,将必要的运行信息通过输出接口进行输出.本次作业对性能要求非常宽松,不需要进行优化处理.…

OO第二次博客作业 零.写在前面 OO第二单元宣告结束,在这个单元里自己算是真正对面向对象编程产生了比较深刻的理解,也认识到了一个合理的架构为编程带来的极大的便利. (挂三次评测分数 看出得分接近等差数列 菜鸡本质暴露无遗) 一.总体设计策略 三次作业设计策略基本相同.前两次是四个类:Main.Elevator.Taker.Waiter:两个线程:main.elevator.第三次在此基础上多了一个类:Dispatcher,一个线程:dispatcher.之所以前两次没有调度器类,是因为由于只有…

在我开始写这次博客作业的时候,窗外响起了希望之花,由此联想到乘坐自己写的电梯FROM-3-TO--1下楼洗澡,然后······ 开个玩笑,这么辣鸡的电梯肯定不会投入实际使用的,何况只是一次作业.还是从中认真分析一下经验和不足吧. 作业一:FIFO单电梯 现在看起来,作业一的难度在整个单元真的仅仅相当于热身.使用线程安全的集合类ConcurrentLinkedQueue存储线程,再用while(true)轮询的方法实现电梯的获取请求,获得请求后运行电梯,运行结束后等待下一个请求即可.整个程序甚至不…

一次又一次的挑战,一次又一次全新的知识,我来到了多线程的面前 第五次作业 1.度量分析 >第五次作业由于很大程度上调用的是前两次电梯的一些代码,所以存在的问题与前几次也十分相似.同时由于第一次使用多线程来解决问题,可能将某些功能过于集中的放在了个别类中.导致McCabe Cyclomatic Complexity以及Nested Block Depth出现标红的现象. 2.类图 >这次在类图上面问题体现的也很明显,在方法的分配上并没有做的很平均.这主要是由于为第一次多线程作业,所以将大部分的功…

一.三次作业总结 1. 说在前面 对于这次的这三次电梯作业,我采用了和几乎所有人都不同的架构:将每个人当作一个线程.这样做有一定的好处:它使得整个问题的建模更加自然,并且在后期人员调度变得复杂时,可以将调度器上纷繁的逻辑判断分布在不同的人身上,大大简化了代码逻辑.对于程序复杂度,将人作为某个容器中的PersonRequest时需要在电梯到达某一层时进行遍历,而将人作为线程池中的一个任务则是通过wait()和notify()机制实现了类似的线程遍历,对于此次最多40人的简单任务而言并不会在时间上损…

多线程协同与同步控制总结 第五次作业-多线程电梯 本次作业是我第一次接触多线程,建立了请求模拟器.调度器和电梯运行三种线程.请求模拟器负责在输入后识别有效请求:调度器在扫描有效请求后将新的请求加入请求队列,并扫描三部电梯的信息,最后遍历请求队列中的请求进行调度,并根据得到的信息进行请求状态和请求队列的更新:电梯运行线程则根据得到的信息进行运动,同时改编电梯信息.实现多线程功能中最大的挑战是实现共享数据的安全.避免冲突(一开始没有加synchronized修饰符导致出现很多bug),因此在与同学讨…

第一次作业 1. 设计策略 第一次作业,一共三个线程,主线程.输入线程和电梯线程,有一个共享对象--调度器(队列). 调度的策略大多集中到了电梯里,调度器反而只剩下一个队列. 2. 基于度量的分析 类图: 方法复杂度: 如上所说,调度的策略大多集中到了电梯里,导致电梯的run方法复杂度大大提升. 类复杂度: solid原则: Single Responsibility Principle (单一功能原则): 基本满足,电梯.输入处理.调度队列的功能职责都只归属于一个类. Open Close P…

过去三周里,我们完成了多线程电梯的程序设计与构造.这是我第一次接触多线程编程.我感觉最大的困难在于多个线程中的操作,谁先谁后,不是像以前写的单线程程序那样严格确定,所以心里常常会比较慌.尤其是因为多线程运行有一定随机性,常常可能会发生bug无法复现的情况,或者是代码有风险但碰巧测试运行时没有出现问题. 一.设计策略总结 电梯问题的多线程设计,与理论课上学习的生产者消费者模型是比较类似的.请求队列支持插入新的请求和弹出请求(给电梯).仿照生产者消费者模型,把读线程看作生产者,把电梯线程看作消费者,…

三次作业的设计策略 第一次作业 多线程协同控制 第一次作业只需要两个线程和一个公共缓冲区: 负责读取输入并把它添加进命令队列的线程,即生产者 负责从命令队列中取出命令执行的线程,即消费者 再加上一个缓冲区:命令队列 相对应的线程之间的互斥和同步操作及对应的处理方法 互斥操作: 互斥1:对命令队列的读-写操作和写-写操作之间的互斥: 我采用的方法是使用Java的ReadWriteLock来实现互斥操作,通过封装Vector类为自己的线程安全的命令队列类,实现读-写互斥和写-写互斥. 互斥2:为了实…