公司网站建设推广词,常德网站优化哪家好,合肥品牌网站建设,南京专业的网站设计团队CPU调度我们知道#xff0c;程序需要获得CPU的资源才能被调度和执行#xff0c;那么当一个进程由于某种原因放弃CPU然后进入阻塞状态#xff0c;下一个获得CPU资源去被调度执行的进程会是谁呢#xff1f;下图中#xff0c;进程1因为阻塞放弃CPU资源#xff0c;此时#…CPU调度我们知道程序需要获得CPU的资源才能被调度和执行那么当一个进程由于某种原因放弃CPU然后进入阻塞状态下一个获得CPU资源去被调度执行的进程会是谁呢下图中进程1因为阻塞放弃CPU资源此时进程2刚IO操作结束可以获得CPU资源去被调度进程3的时间片轮转结束也同样可以获得CPU资源去被调度那么此时的操作系统应该安排哪个进程去获得CPU资源呢这就涉及到我们操作系统的CPU调度策略了。根据生活中的例子我们很容易想到以下两种策略CPU调度的直观想法1.FIFO谁先进入先调度谁这是一种非常简单有效的方法就好比我们去饭堂打饭谁先到就给谁先打饭。但是这种策略会遇到一个问题如果遇到一个很小的任务但是它是最后进入的那么必须得前面一大堆任务结束完后才能执行这个小小的任务这样就感觉很不划算呀因为我只是简简单单的一个小任务但是从打开这个任务到结束这个任务要很久。这显然不符合我们的需求因而我们会想到第2种策略就是先调度小任务后调度大任务。2.Priority很简单就是任务短的优先执行但是此时又有问题了任务虽然短但是它的执行时间不一定短就好比在一个银行业务中客户填写一个表这是一个非常短的任务吧——就单单填个表但是这个表很长很长那么这个短任务它的执行时间就很长了我们怎么知道这个短的任务将来会执行多长的时间呢所以这样的策略还是依然有问题。那么面对诸多的场景如何设计调度算法呢首先我们要明白我们的算法应该让什么更好呢面对客户银行调度算法的设计目标应该是让用户满意而面对进程CPU调度的目标应该是进程满意。那怎么才能让进程满意呢那就是时间了。进程希望尽早地结束任务这就是周转时间(从任务到达到任务结束)要短而且希望用户的操作能够尽快地被响应这就是响应时间(从操作发生到响应)要短。而且系统内耗时间要少吞吐量(任务的完成量)要大系统需要把更多的时间用在任务的执行上而不能老是去做无关紧要的事情例如频繁切换任务切换栈分配资源等事情。同时系统还要合理地调配任务。那么CPU的调度策略如何做到合理呢首先得明白系统中有以下的几种矛盾。1.吞吐量和响应时间之间有矛盾响应时间小切换次数多系统内耗大吞吐量小由于需要较短的响应时间那么就得频繁地切换任务这样系统的很多时间都花在切换任务上面了系统的内耗大了吞吐量就小了。2.前台任务和后台任务的关注点不同前台任务关注响应时间后台任务关注周转时间。前台任务例如我们的word文档我们打一个字需要立马显示在文档中这就是word文档这个任务关注的是响应时间而后台任务中例如我们的javac编译java代码它的周转时间要小即该任务从进入到结束所花的时间要小即编译完成的时间要小。http://3.IO约束型任务和CPU约束型任务各有各的特点IO约束型任务就是使用CPU的时间较少进行IO操作的时间较长CPU约束型的任务就是使用CPU的时间较长。因此要做到合理需要折中、综合考虑以上的几种矛盾由此产生了以下一些CPU的调度算法。各种CPU调度算法1.First ComeFirst Served(FCFS)就是先来先服务的调度算法哪个任务先进来就为哪个任务先服务。我们上面说过周转时间任务结束的时间-任务到达的时间因此我们算一算以上四个任务的平均周转时间。进程A到达时间为0时刻进程B到达时间为1时刻进程C到达时间为2时刻进程D到达时间为3时刻因此按照FCFS调度算法我们一词调度A、B、C、D.四个任务的平均周转时间(5-0)(65-1)(165-2)(175-3) / 4 101.那么因为一个系统中可能短任务占的比重较多那些后来进入的短任务就得等前面一大堆的任务执行完后CPU才为这些短任务服务这样的话很多短任务即使服务时间短但是它们的周转时间都比较长。我们可以尝试着把短任务提前短任务提前了减少以短任务为主的系统的平均周转时间由此我们产生了短作业优先的CPU调度算法。资料直通车最新Linux内核源码资料文档视频资料内核学习地址Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈2.SJF(Short Job First短作业优先)也很简单就是哪个任务的服务时间短就先调度哪个。还是上面那四个进程。进程A的服务时间为5进程B的服务时间为60进程C的服务时间为100进程D的服务时间为10因此按照短作业优先的CPU调度算法我们依次调度A、D、B、C.因此这四个任务的平均周转时间(5-0)(15-3)(75-1)(175-2) / 4 66.很明显看到在以短作业为主的系统中短作业优先的调度算法的平均周转时间比先来先服务的调度算法平均周转时间要低.现在问题又来了如果任务C这个任务是急需要响应的比如是word文档任务那么它就要快速响应用户的按键输入请求就是要求其响应时间要小。很明显上面的SJF调度策略没有考虑到响应时间这个问题使得任务C仅仅是周转时间短而下响应时间较长(必须等A、D、B任务结束后才会响应C)。由此我们想到了按时间轮转的方式去调度。3.RR算法(按时间片来轮转调度)还是以上面的那四个进程为例。那按时间片轮转的调度算法是设置一个时间片比如为10的CPU时间然后不停地在A、B、C、D四个进程中切换每个进程执行时间10时间到了就切换到下一个进程执行时间10直到全部执行完毕。为每个进程分配10的CPU时间轮转调度执行这样每个进程的响应时间就变小了。如果时间片设置过大那响应的时间就会太长如果时间片设置过小那整个系统都在不停地切换进程系统很多时间都浪费在切换进程上面了造成系统的吞吐量小折中考虑后时间片设置为10~100ms切换的时间为0.1~1ms.说到这里SJF算法是关注系统的平均周转时间而RR算法是关注系统的响应时间但是如果一个系统需要响应时间小和周转时间小同时存在那该怎么办比如word很关心响应时间而javac编译java程序更关心周转时间两类任务同时存在该怎么办前台的任务更关心响应时间因为前台任务是与用户直接进行交互的需要快速响应用户的请求后台任务更关心周转时间需要快速的结束任务的。一个很直观的想法定义前台任务和后台任务两条队列前台使用RR算法后台使用SJF算法只有前台任务没有时才调度后台任务。但是这样又会产生问题如果一直有前台任务怎么办那这样后台任务就永远得不到调度了。在这里有一个有趣的小故事想跟大家讲1973年有位工作人员去关闭MIT的IBM7094计算机时发现有一个进程在1967年提交但一直未运行。这时候我们可以让后台的任务优先级动态升高但后台任务(用SJF调度)一旦执行那前台任务的响应时间又得变大了。如果我们前后台任务都用时间片那又退化为了RR算法。所以问题还有很多等着我们去发现去想办法解决。如我们怎么知道哪些是前台任务哪些是后台任务呢前台任务难道就没有后台任务的工作后台任务难道没有前台任务的工作SJF中的短作业优先如何体现如何判断作业的长度等等这些问题到现在都在疯狂地探讨和研究当中有兴趣向这方面进行深入了解的可以阅读相关文献或者阅读以下linux的CPU调度算法源码。单单一个CPU的调度算法就要考虑这么多东西了可以看到我们的操作系统真的是人类的一项很伟大的发明。
