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

oo第二单元博客总结 在第一单元求导结束后,迎来了第二单元的多线程电梯的问题,在本单元前两次作业中个人主要应用两个线程,采用“生产者-消费者”模式和共享数据变量的方式解决问题.在第三次作业中加入多个电梯线程以后,沿用之前的模式,但是在控制线程的地方进行了部分相应的修改保证任务的完成. 第一次作业—傻瓜电梯 第一次作业是没有任何调度算法的傻瓜电梯,生产者生产请求,将请求加入存储的仓库队列.消费者消费请求,循环从仓库中取出请求,取出一个请求即运送他,直至运送完毕后,再进行循环. 下面是第一次作业的类…

OO第二单元优化博客 第五次作业没有性能分,但是,我在这一单元的宗旨就是写一个日常生活中 最常见的那种电梯,所以第五次我没有写傻瓜电梯,而是直接写了个\(look\),和第六次基本相同. 总计一下look算法的几个特点: 1.没有主次请求的区分. 2.电梯会一直往当前方向运行直到需要转向,转向条件为: ​ (1)当前电梯中没有乘客的目的楼层在当前方向上. ​ (2)当前方向上的楼层目前没有请求. 3.捎带时只捎带请求与当前方向相同的乘客. ​ (由于第五次第六次作业没有容量限制,所以可以把当前楼…

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

OO第二单元作业总结 在第二单元作业中,我们通过多线程的手段实现了电梯调度,前两次作业是单电梯调度,第三次作业是多电梯调度.这个单元中的性能分要求是完成所有请求的时间最短,因此在简单实现电梯调度的基础上,我还使用了一些调度算法来追求性能分,但是效果上不是很理想,只能勉强获得90分,在这里我想把我自己的做法写出了,供大家参考. 本次作业分为以下部分,三次作业实现介绍(包括调度方法), 总结作业.请读者各取所需. (注:本次电梯的全部调度算法仅针对作业题目,对实际情况并不相符) 三次作业实现 第一次…

OO~第二次作业总结 连续三周的电梯作业结束了,总的来说这三次作业做的还算平稳,既没有被刀,也没有刀中别人.那么接下来开始谈谈我对这三次作业的认识. 一.设计策略 我三次作业的设计思路基本上是相同的,电梯主要分成了三个线程,即Input(输入线程).Scheduler(调度器).Elevator(电梯).在这三个线程之间通过两个不同的托盘进行数据交互,即把输入线程输入的电梯指令放入调度器的ArrayList中,然后再用傻瓜调度算法/可稍带算法将相应指令传给电梯,最后电梯执行指令并输出相应结果.…

OO第二单元小结 一.三次作业代码分析. 1.第一次作业 第一次作业是单部电梯的傻瓜调度,由于其过分傻瓜,所以第一次作业我只有两个类,一个main,一个电梯,main类负责不断从输入流中读取命令,如果输入空则退出,否则将这条命令交给电梯去run,而电梯需要做的事情就是从当前楼层去接人,然后将之送达目的地即可.第一次作业基本没有使用多线程的思想,但是正确性是无懈可击的. 其实为了学习和使用多线程知识,我也写了一个多线程版本的傻瓜调度,其设计与第二次作业几乎相同,不同点就只在电梯的运行方法上有所不同…

OO第二单元多线程电梯总结 第一次作业 设计思路 Input为输入线程,负责不断读取请求并将读到的请求放入调度器中. Dispatcher为调度器,是Input线程和Elevator线程的共享对象,采用单例模式.Dispatcher中list为请求队列,over为输入线程结束的标志,当输入线程读到null时,将over设为true. Elevator为电梯线程,采用傻瓜调度(FAFS). 代码分析 SOLID原则分析 Input线程负责输入,elevator线程负责取指令执行的单一负责线程比较好…

OO第二次单元总结 前言 第二单元的三次作业:系列电梯与多线程. 第五次作业 (1)设计策略 电梯的第一次作业是单部傻瓜电梯,采用FAFS调度策略,电梯按队列顺序依次处理请求,单次只处理一个请求.本次作业采用了简单的生产者-消费者模式,而调度器则采用了单例模式. (2)基于度量来分析自己的程序结构 类图: 复杂度分析: 依赖度分析: 本次作业很简单,共设计了四个类,除主线程外包含一个请求输入线程和一个电梯线程.Scheduler类为单例模式调度器,内部有一个请求队列.Input类负责请求的获取和…

OO第二次单元总结--电梯多线程调度问题 在这个单元OO学习中,我们终于迎来了期待已久(不是)的电梯多线程调度作业,开启了OO打怪之路的新关卡.虽然说经过了这三次作业,我对于多线程的理解还不能算是熟练,在线程控制方面的实现也仍有缺陷,但是经过了磕磕绊绊的写作业过程也达到了可以对多线程进行简单应用的程度.在此,我对于第二单元的OO作业进行一个总结,梳理一下自己这三次作业中的实现方式以及所踩过的大雷. 第一次电梯作业 (1)设计策略 题目要求 单部多线程傻瓜调度(FAFS)电梯的模拟,实现对于一个目…

OO第二章总结 电梯作业终于结束了!!! 这三周作业用多线程模拟搭建电梯的运行,我从开始对多线程的一无所知到结束时的能够完成一些多线程任务的水平,进步还是蛮大的,尽管过程有点艰难. 一.复杂度与UML图分析 第一次作业 UML Person类在本次作业没有用到,我只是预留了一个扩展类.MainClass类作为启动,PassengerQueue类是共享资源类,也就是生产者消费者模式的那个传送带.Input是生产者,Elevator是消费者. 复杂度分析 电梯类的WMC很高,也就是循环复杂度很高,代…

oo第二单元作业总结 一.设计策略与质量分析 第一次作业 设计策略 在第一次作业之前,我首先确定了生产者--消费者模式的大体架构,即由输入线程(可与主线程合并)充当生产者,电梯线程充当消费者,二者不直接交互,而是在Controller类的成员变量等待队列中不断取出或放入请求以达到交互的目的.而对于调度器位置的考虑,我将其与电梯线程合并,即从宏观上来看,电梯本身不断与请求队列交互,并按照自己的策略决定是否移动.开关门等(这一架构正是后两次作业中无为而治的基础).在此基础上,添加一些线程结束的判断以…

2020北航OO第二单元总结 前言 本单元考察基于多线程的电梯调度问题,成功让我从一个多线程小白到了基本掌握了使用锁来控制线程安全的能力,收获颇多(充分体验了迷茫地de一个又一个死锁bug的痛苦). 三次作业的关键如下: 第一次作业:单台电梯的调度,电梯可到达所有楼层,容量不设限,考虑捎带. 第二次作业:多台电梯的调度,通过输入控制电梯台数,电梯可到达所有楼层,容量受限,考虑捎带. 第三次作业:3+n台电梯的调度,通过输入随时增加电梯,电梯到达楼层.容量.运行时间分类受限,考虑换乘和捎带. 一.…

OO第二单元--多线程(电梯) 综述 第二单元的三次联系作业都写电梯,要求逐步提高,对于多线程的掌握也进一步加深.本次作业全部都给出了输入输出文件,也就避免了正则表达式判断输入输出是否合法的问题. 第一次作业--单部电梯(无调度)论述 第一次作业,是写一部电梯的模拟器,指导书提供了一个极为基础或者说不叫算法的算法,只需要将人送到正确楼层即可,对于时间.性能没有任何要求,但也是我们第一次尝试多线程,开始写代码时对于wait(),notify()函数并不是十分了解,导致出现了各种线程不安全,或是出现…

“欢迎来到(玄学)多线程的新世界” Homework1 单部傻瓜电梯调度 Part1 多线程设计策略 第一次学到了线程这个概念,与之前的编程体验大有不同.最大的区别在于从原本的线性发生程序变成了多个行为并行发生,思考量直接从o(n)变成了o(n^2).值得一提的是,由于这次电梯作业只有一部电梯,而且调度算法极为简单,FAFS(先来先服务)的傻瓜式调度似乎已经不太需要多线程,放到正常单线程里也许才不到百行.不过笔者考虑到今后可能的魔鬼电梯(事实证明确实魔鬼),还是义无反顾的使用了多线程. 第一次多…

第二单元作业的完成史,就是一部心酸的血泪史…… 多线程的出现为我(们)打开一片广阔的天地,我也在这方天地摸爬滚打,不断成长!如果说第一单元之前还对Java语法有所了解的话,那么这单元学习多线程则完全是从0积累的一个过程.每一步,都走得很艰难!虽然我犯过很多错,但我很庆幸,我坚持到了最后! 写在前面 单线程:Java程序在虚拟机上运行,一个Java程序对应一个JVM实例,同时对应一个主线程(即main),程序入口从main进入,运行完毕从main退出. 多线程:顾名思义,即不止一个main线程,m…

三周复三周,一轮又一轮,我似乎已经将OO是为我的生活必须品了.在与同学吐槽者身负-3楼与20楼重任的A电梯君,以及我们都是上一层下两层不用电梯的五号青年的等等欢声笑语中结束了第二轮的OO作业.当然这次也是收获颇丰,我通过电梯了解了线程的工作原理,认识到了线程安全的重要性,下面我将对自己 的三次作业进行一下总结. 一.基于度量的程序结构分析 作业一 (1)总结 第一次电梯还是比较简单的,所以我采用生产者消费者模式就很容易的解决了. (2)耦合度 可以看出电梯线程还是承担了太多的事情,不易维护. 第…

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

OO第一单元(求导)单元总结 这是我们OO课程的第二个单元,这个单元的主要目的是让我们熟悉理解和掌握多线程的思想和方法.这个单元以电梯为主题,从一开始的最简单的单部傻瓜调度(FAFS)电梯到最后的多部多线程智能调度(SS)电梯,我们需要掌握的多线程知识也从简单的线程间交互与同步到多种多线程模式相结合的复杂线程调度系统. 一.作业分析 第一次作业 第一次作业要求实现的是单部多线程傻瓜调度(FAFS)电梯的模拟.即一次接送一个人的VIP式电梯. 这个版本的作业其实不是我提交时所用的版本,而是我在提交…

总结性博客作业 (1)从多线程的协同和同步控制方面,分析和总结自己三次作业的设计策略. (2)基于度量来分析自己的程序结构度量类的属性个数.方法个数.每个方法规模.每个方法的控制分支数目.类总代码规模计算经典的OO度量画出自己作业的类图,并自我点评优点和缺点,要结合类图做分析通过UML的协作图(sequence diagram)来展示线程之间的协作关系(别忘记主线程)从设计原则检查角度,检查自己的设计,并按照SOLID列出所存在的问题 (3)分析自己程序的bug分析未通过的公测用例和被互测发现的…

前言: 第二单元总共包括三次电梯调度作业.这三次作业在笔者看来是为了让学生了解什么是多线程,多线程的好处及可能存在的潜在问题,对于多线程的安全问题应该如何解决和保证结果的唯一性和正确性.那么接下来笔者将结合三次电梯调度作业来谈谈在这三次作业中我都收获了哪些. 第五次作业: 结构分析: 代码分析: 第五次作业相对来说结构比较简单:Main方法调用静态对象调度器,然后作为参数传入输入和电梯实例出来的两个对象中,最后开启这两个线程.唯一需要注意的就是对调度器中任务链表进行操作的时候一定要记得加锁,也就…

总述 OO的第二单元主题是电梯调度,与第一单元注重对数据的输入输出的处理.性能的优化不同,第二单元的重心更多的是在线程安全与线程通信上.这此次单元实验之前,我并未对线程有过了解,更谈不上“使用经验”,整体上第二单元三个实验也做的较为吃力.三次实验,也算是对线程的一步步入门吧,以及由于对于线程不是很熟悉,所以我总是下意识的把程序分割,尽量减少通信量. 第一次实验 基本需求:单电梯.无捎带要求.基本无性能要求. 基本实现:一个主线程或者一个主线程与一个电梯线程 我采用的方法是使用一个主线程,因为实际…

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

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

OO电梯作业总结 这三周的作业和课堂内容以及OS的课上内容都相同,都是关于多线程方面的知识.在这次作业中由浅入深布置了三项多线程电梯方面的作业,让我们在实践中感受了多线程的工作原理以及各项需要注意的要素. 一.第一次作业 第一次作业是典型的生产者消费者问题,只不过生产者不必考虑容器装满的特殊情况.在这次电梯作业中电梯只需要将乘客送往目标楼层,不需要解决沿路搭顺风车等其他需要解决的特殊情况.当负责输入的生产者停止时,设置一个共享的结束变量结束整个电梯的运行,整个电梯的运行结构如下图所示: 如图所示…

一.设计策略. 在三次作业中,多线程程序的实现分以下几个步骤: 1. 主线程Main类的创建多个线程. 2. 共享对象的synchronized锁保证线程之间的互斥访问. 3. 采用notifyAll和wait的方式实现同步控制,第三次作业中少部分采用sleep(10)的轮询机制(本希望能去掉,但时间不足). 4. 结束指令NULL的异步传递(传递到共享对象中,由各个线程读取)结束线程. 第一次作业的结构比较好,耦合度低,使得第二次作业轻松摸鱼,修改很少,但没有为下一次作业修改架构.后果是第三次…

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

前言 ​ 第二单元 OO 作业的主题是多线程,课程组通过了电梯调度这个经典问题考察了多线程的调度. ​ 从第五次作业到第七次作业的迭代为,单部多线程可捎带电梯,多部多线程可捎带调度电梯(电梯属性相同)和多部多线程可捎带调度电梯(电梯属性不同,包含需换乘请求) 一.作业分析 作业分析将通过代码复杂度度量,UML 协作图,扩展性,优缺点等方面进行分析 第五次作业 ​ 第五次作业的任务是完成单部可捎带电梯的调度. 设计分析: 第一次多线程作业中,我初步设想的是有三个线程,一个输入线程,一个调度线程,一…

只要跑得够快即使从头关到尾你也喜欢吗? 一.设计策略 1.1 总体策略概述 在多线程的协同和同步控制方面,我三次作业都是采用生产者/消费者模式(还憨憨地在内部分了customer.producer.tray的包--方便自己看orz). 其中"生产者"为输入线程,将读取到的Request放到"货架"Scheduler上:"消费者"则是每个电梯线程,以一种类似观察者模式的方式追踪"货架"Scheduler的变化.之所以说是类似,是…

目录 目录一.第一次作业分析设计策略基于度量分析程序结构二.第二次作业分析设计策略基于度量分析程序结构三.第三次作业分析设计策略基于度量分析程序结构四.分析自己程序的bug五.发现别人程序bug所采用的策略六.心得体会线程安全设计原则 一.第一次作业分析 设计策略 采用生产者-消费者模式,调度器作为托盘,请求处理器不断向托盘提交请求,电梯不断从托盘中获取请求执行,当托盘为空时,进入等待.其中调度器是共享对象,请求处理器和电梯是两个线程. 线程安全方面,由于理论知识不扎实,由请求处理器和电梯分别管…