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

一.概述 这一部分的作业考察的关注点与上一次的作业有所不同,上一次的考察重点主要集中在输入输出的判定以及多态的考察上面,而这一次是让我们进行多线程程序的调度与开发.这次开发过程中最大的感受就是自己之前的程序好像都白写了...需要自己去探索掌握的东西有许多.在之前的作业中我们都是尽可能地使用加断点的方式进行调试,因为每次程序运行不会产生二义性,即对就是对错就是错,这时printlog就成为了十分有效的debug方式.同时这一系列的作业是对上一次多态思想的继承,即第一次作业在设计的时候就需要弄清楚可…

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

在电梯系列的作业中,笔者的整体架构几乎没有发生改变.现介绍如下,对于一个电梯系统,主要的工作步骤就是获取乘客请求.分派请求.执行请求.针对这样的工作模式,笔者设计了Elevator.Uselist两个主要的类(获取请求由主类完成).在线程的配合方面,笔者采用的是消费者-生产者模式,Uselist相当于托盘,不同的是该类还负责向不同的电梯分配请求. 一.作业分析 (一)第一次作业 调度算法:严格采用可稍带原则,中途楼层遇到新的乘客就进行搭载. UML类图: 复杂度分析: 由于只有一部电梯,因此方法…

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

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

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

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

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

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

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

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

前言 转眼已是第九周,第二单元的电梯系列作业已经结束,终于体验了一番多线程电梯之旅. 第一次作业是单电梯的傻瓜调度,虽然是第一次写多线程,但在课程PPT的指引下,写起来还是非常容易:第二次作业是单电梯的捎带调度,并加入了负层电梯,写起来也相对容易,不过在写捎带策略时容易出很多BUG:第三次作业是多电梯协作调度,不同电梯有不同的停靠楼层.容量等,看起来好像比较难,但其实只要将请求拆分,并且有第二次作业的代码基础,需要大改的也基本上只有调度器而已. 相比于第一单元借助延时才完成作业,这一单元的作业我…

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

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

经过第一单元作业的训练,在做第二单元的作业的时候,要更加的有条理.但是第二次作业多线程的运行,带来了更多的运行的不确定性.呈现出来就是程序会出现由于线程安全问题带来的不可复现的bug.本单元的作业也让我更加认真的思考了性能和架构之间的关系,对于工程架构的设计有更进一步的认识. 历次作业分析和总结: 第一次作业:单电梯的傻瓜调度 类图如下: 第一次作业由于并没有性能要求并且刚刚接触多线程的运行,程序的结构简单并且多线程的各个线程之间并没有很多的交互.第一次作业设计中为了第二次作业的扩展,只是简单的…

电梯系列第一次作业 功能描述: 傻瓜电梯无需考虑超载捎带 线程模式: Producer-Consumer Pattern 思路: 第一次作业是一个傻瓜电梯,分别有一个生产者生成电梯指令(也就是Input接口),和一个消费者电梯(Process)运行指令和一个电梯调度器, 调度器为生产者和消费者共享,在生产和消费指令时,给队列上同一把锁,再通过wait();和notify(); 进行阻塞和唤醒调度器将生产者生产的命令放入电梯中,存放指令的队列使用的是Arrylist.   线程安全: 由于Arra…

在初步认识了面向对象思想后,立刻进入了多线程的学习,本单元的难点主要是锁的理解,需要保证线程安全的同时防止死锁的发生,也要尽可能缩小锁的范围,提高性能.这一单元以电梯为载体,让我们从生活出发,从电梯运行的角度理解多线程,同时学习和应用生产者-消费者模式来帮助我们编程.在一部可捎带电梯的基础上越来越贴近生活,进行了电梯数量的扩展,载客人数的限制 homework5 这次作业是单部可捎带电梯,主要是初步应用多线程编程,保证线程安全,防止死锁的发生. UML 采用生产者-消费者模型,Main类创建其他…

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

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

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

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

OO的第二单元是讲多线程的协作与控制,三次作业分别为FAFS电梯,ALS电梯和三部需要协作的电梯.三次作业由浅入深,让我们逐渐理解多线程的工作原理和运行状况. 第一次作业: 第一次作业是傻瓜电梯,也就是完全不需要考虑捎带策略,只需要简单的把每一个人都送到目的楼层就可以.与以往写过的程序不同的是,这次要采取多线程的 模式,输入和输出并不同时,输入是按照时间投放的,输出也要包含时间信息.这次作业主要是想教会我们生产者--消费者模型的使用.然而,在第一次写这次作业的时候,我把输入当成生产者,调度器当作…

第二单元(线程与电梯问题)总结博客 三次作业的设计策略 第一次:本次作业只有一部电梯,而且不用捎带.因此,我一共设计了两个线程:一个负责管理输入,一个负责电梯运行.同时,我将调度队列设置为单例模式,里面存储着一个队列.由于是存一次取一次,所以我在该单例模式中的方法使用了生产者消费者模式:input一个,get一个. 第二次:本次作业依旧是一部电梯,但是需要捎带.由于本质上还是一部电梯,所以我依旧没把调度器写成线程.依旧是一个线程负责输入,一个线程负责电梯运行.但是这次由于要稍带,调度器的方法就不…

在经过第一单元初步认识面向对象编程思想后,本蒟蒻开始了第二单元--多线程部分的学习.本单元的作业是构造符合条件的"目的选层电梯"模型,自行设计调度算法,进行合理调度,完成所有乘客的需求.由于电梯请求与运行均为实时操作,因此需要采用多线程设计. 第一次作业 1.构造阶段 本次作业的需求是设计单部可捎带的目的选层电梯,电梯楼层为1~15层,捎带策略可自行设计,电梯容量没有限制.我在综合比较多种电梯调度算法后,采取了以下的调度策略:当电梯内无人时,采用LOOK算法:当电梯内有人时,采用指导书…

第二单元多线程作业需要保证线程安全…

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

需求分析 官方需求 本次作业需要模拟一个多线程实时多电梯系统,从标准输入中输入请求信息,程序进行接收和处理,模拟电梯运行,将必要的运行信息通过输出接口进行输出. 本次作业电梯系统具有的功能为:上下行,开关门.本次多部电梯的可停靠楼层,运行时间,最大载客量都不相同. 电梯系统可以采用任意的调度策略,即上行还是下行,是否在某层开关门,都可自定义,只要保证在系统限制时间内将所有的乘客送至目的地即可. 电梯系统在某一层开关门时间内可以上下乘客,开关门的边界时间都可以上下乘客. 简要分析 这次作业有几个关…

写在前面 这三次电梯调度作业,主要是学习多线程并行操作,对于各个线程的时间轴的把握,互相的配合与影响,通过使用锁来解决访问冲突等方面. 个人在学会Thread相关操作之外,写出来一些奇怪结构的诡异操作,而这些操作是在已有方法学习不精的情况下意外获得,虽然后期证明效率不高,但也是扩宽了代码思路,将在下文一一说明. 另外有一些经验教训作为后鉴. 作业要求与代码结构 第一次作业 作业要求:单部单人电梯,目的选层调度,一到十五层运行. 代码结构: 此次作业我写的极其简单只有六十余行,同时拓展性也几乎为0…

一.设计策略及程序结构分析 1.第一次作业 第一次作业是需要我们用多线程模拟一个实时电梯系统,功能比较简单正常,但要有捎带功能,我采用的调度策略便是指导书上提供的ALS调度策略,采用消费者-生产者模式,生产者即输入类,不断输入人的电梯请求,消费者就是电梯类,不断接受输入过来的电梯请求,并不断执行下去,中间的仓库类便是调度器,负责存储输入类即生产者提供的请求,并经过一定的调度策略将电梯请求交给电梯去执行. 但调度器要获取电梯的实时状态,却不能一个线程直接调用另一个线程,所以我是采用了这样的设计策略…