In FIFO: when process get cpu time and then go to IO. What happend in the time it is in IO? another process can run? After finishing IO it continue or "loss its turn"? Why FIFO give priority to cpu bound process?
In RR: assume slice time is s and after (s-2) for eample it get IO, what happend with the 2 other seconds? it loss them?
3.In preemptive SJF we look on the next cpu burst. What about non preemptive SJF? we lock on all the cpu in the process will need?And in genreal we look only on cpu? not on io?
Asked By : user2459338
Answered By : Wandering Logic
Each program in the system is in one of three states: running (currently using the cpu), waiting (for i/o), or ready (not waiting for i/o, but not currently using the cpu). When discussing scheduling disciplines jobs are not programs, rather each burst of cpu usage between i/o requests in a program is a job.
First-in-first-out (FIFO), round-robin (RR) and shortest job first (SJF) are scheduling disciplines for choosing the next job to run from the ready queue of the operating system. So in all three cases the jobs under discussion correspond to the set of processes that are currently in the ready state.
In FIFO as each job reaches the head of the queue it gets the cpu, when the job requests i/o then it is done. The process (not the job) enters state waiting. When the i/o is done the process is moved from state waiting to state ready, and the job corresponding to its next burst of cpu is put on the back of the FIFO queue.
A cpu bound process is one where the average cpu bursts (the jobs) are much longer than the average time spent waiting for each i/o. Since FIFO is non-preemptive when a long cpu-burst gets to the head of the queue and starts running, all of the ready processes in the queue behind that job are stuck.
In round-robin we are also referring to jobs, not processes. When a job requests i/o it is done. When the process goes from waiting to ready the next job (cpu burst) from that process joins the round-robin queue.
Non-preemptive shortest job first is only practical if you really have future knowledge about exactly how long the jobs are. If some jobs are taking longer than you expected and you aren't preempting them, then you're not really running the shortest one first.
In general scheduling disciplines are only looking at the jobs in the ready queue. One of the points of SJF, though, is to make sure that the i/o system is kept as busy as possible. Jobs usually end with an i/o request, so by scheduling the shortest job first you are getting to the next i/o request the soonest.
This insight about shortest job first is what is behind the multi-level feedback queue scheduling used in most modern operating systems: you are using past behavior to predict future job lengths, and then scheduling (expected) shortest job first (but preempting the job if it goes much beyond its expected length.) The classic paper is Corbató, F. J., M. M. Daggett, and R. C. Daley, "An experimental time-sharing system", AFIPS Conference Proceedings, Vol. 21, pp. 335-344, 1962.
Best Answer from StackOverflow
Question Source : http://cs.stackexchange.com/questions/13426
0 comments:
Post a Comment
Let us know your responses and feedback