What happens in preemptive SSTF algorithm if the arriving process has the same burst time (shortest) as the currently running process at that instance? Will running process continue to run or the processor will switch to the arriving process?
Example: At time instance 4, P1 has the remaining time of 6 ms and a new process p2 arrives with a burst of 6 ms, will P1 continue to run or process will switch to P2?
That is entirely system dependent. It may break the tie using the smallest arrival time first or it may be simply the priority of the jobs. In general it is the priority which is determined by number of factors. That saves you from stucking a process in same state for long. These are the common way using which the problem is resolved.
So long story short it depends on implementation.
Related
In Multilevel Feedback Scheduling at the base level queue, the processes circulate in round robin fashion until they complete and leave the system. Processes in the base level queue can also be scheduled on a first come first served basis.
Why can't they be scheduled on Shortest Job First (SJF) algorithm instead of First Come First Serve (FCFS) algorithm which seems to improve average performance of the algorithm.
One simple reason:
The processes fall in the base level queue after they fail to finish in the time quantum alloted to them in the higher level queues. If you implement SJF algorithm in the base level queue, you may starve a process because shorter job may keep coming before a longer executing process ever gets the CPU.
The SJF algorithm gives more througput, only when processes differ a lot in their burst time. However its not always the case that it will perform better than FCFS. Take a loot at this answer.
Since in Multilevel Feedback Scheduling algorithm, all the processes that are unable to complete execution within defined time quantum of first 2 queues, are put to the last queue having FCFS, its very likely that they all have large CPU bursts and therefore wont differ much in their burst time. Hence, its preferred to have FCFS, scheduling for the last queue.
I'm studying task-based parallel computing and got interested in a variation of the old project management problem -- the critical path of an activity-on-vertex (AOV) project network, which can be calculated using the topological sorting algorithm if there's no deadlock cycle. The total time of those activities on a critical path gives the minimum completion time of the project.
But this is assuming we always have enough workers simultaneously finishing the activities with no dependence on each other. If the number of workers (processors/cores) available is finite, certain activities can wait not because some activities they depend on have not yet been finished, but simply because all workers are now busy doing other activities. This is a simplified model for today's multi-core parallel computing. If there's only one worker who has to do all the activities, the project completion time is the total time of all activities. We are back to single-core serial computing that way.
Is there an efficient algorithm that gives the minimum completion time of an AOV network given a finite number of workers available? How should we wisely choose which activities to do first when the doable activities is more than the number of workers so as to minimize the idling time of workers later on? The minimum time should be somewhere in between the critical path time (infinite workers) and the total time of all activities (one worker). It should also be greater than equal to the total time divided by the number of workers (no idling). Is there an algorithm to get that minimum time?
I found a C++ conference video called "work stealing" that almost answers my question. At 18:40, the problem is said on the slide to be NP-hard if activities cannot be paused, further divided, or transferred from worker to worker. Such restrictions make decisions of which workers to finish which jobs (activities) too hard to make. Work stealing is therefore introduced to avoid making such difficult decisions beforehand. Instead, it makes such decions no longer crucial so long as certain apparent greedy rules are followed. The whole project will be always finished as soon as possible under the constraint of either the critical path or the no-idling time of the finite number of workers or both. The video then goes on talking about how to make the procedure of "work stealing" between different workers (processors) more efficient by making the implementation distributed and cache-friendly, etc.
According to the video, future C++ shared-memory parallel coding will be task-based rather than loop-based. To solve a problem, the programmer defines a bunch of tasks to finish and their dependence relations to respect, and then the coding language will automatically schedule the tasks on multiple cores at run time in a flexible way. This "event-driven"-like way of implementing a flexible code by a distributed task queuing system will become very useful in parallel computing.
When an optimization problem is NP-hard, the best way to solve it is to find ways to avoid it.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
So here's the question. While studying about process scheduling I came across two seemingly contradictory examples I just can't get my head around.
The problem arises if for instance in the priority non-preemptive scheduling algorithm which always chooses the process with the highest priority to be run next and once running, process can only volontarily give up its CPU time, that is no other process can run until the currently running process finishes. It seems that what the solution the book proposes is that if both end of one process and arrival of the new high-priority process occur at the same time, the new high-priority process will be added to the ready queue and then chosen by the scheduler to be run next.
But in the other example in Round-robin algorithm, if there is only one process in the ready queue and it is currently running, if at the same time its quantum elapses and new process says its ready, it seems that the proposed solution is that the scheduling will be done first, so the currently running process will continue to run while the new process will be added to the queue.
I'd be grateful if someone clarified this to me, because I know from some other post that context switch does not occur in round robin for single process in queue, but is it true in general that scheduling is done before adding new process to queue.
What I get from you description is:
Time 0:
Process 1 starts using its time slice, e.g. 5 units.
Time 5:
Process 2 arrives.
Process 1 used up its time slice and is replenished.
A round robin scheduler checks the ready queue by selecting the next process with time left.
At time 0 your ready queue looks like this:
P1
At time 5:
P1 going over to P1 -> P2
Tanenbaum writes in Modern Operating Systems: When a process used up it's time slice, it is enqueued at the end. So what happens is, that P1 is enqueued again before P2 is enqueued for the first time. This saves an additional context switch from P1 to P2 and back to P1.
If you want P2 to be run first, then you can use priority base round robin.
I have a scheduling problem where new jobs (sets of tasks whose execution is sequentially connected) arrive every few seconds or so.
Each job requires some resources to be allocated at known intervals.
For example:
Job j1 is a set of tasks for which we reserve resources {r1, r2, r3}
on a known scheduling pattern:
r1:[t0 .. t1=t0+td1],
r2:[t2=t1+td2+i2 .. t3=t2+td3]
t0 being the start time of execution
td1 is the length of the resource allocation for r1
t1 being the end time of the resource allocation for r1
i1 is length of the waiting perioid between r1, r2 and so on.
In the example, a new job j2 is being scheduled right after j1 execution has started.
The earliest start time for j2 is t1.
A job may take some minutes of execution most of which consists of waiting.
I have a scheduler that looks at the current reservation table and decides which is the earliest possible starting moment for a new job with fixed allocation times and waiting periods and makes the reservations accordingly.
(But in reality, the waiting period doesn't really need to be fixed - but within some percentage (maybe 5%) and there may be alternatives to resource usage, for example, if resource r3.1 is booked, then 3.2 may be used as such to achieve the same thing.)
However, if the scheduler is required (yes, it's been suggested) to be able to dynamically adjust all the schedule allocations when a new job arrives to maximize the total work done (in a day) by taking advantage of the fact that the waiting times need not be exactly as given and the possibility to parallel execution with some resrouce duplicates (3.1/3.2), then I'd be looking at a completely different scheduling scheme (than my current start-as-soon-as-possible approach).
What scheduling scheme would you call that then?
Any suggestions on approaching the (new) problem?
As for your question regarding "alternatives to resource usage":
The pattern most commonly implemented to tackle that sort of problem is the Object Pool Pattern
The most widely known example for this probably is the ThreadPool
I suggest you implement a ResourcePool class with a int GetResource(ResourceType type, int durationInSeconds) method.
The return value indicates when the next resource of the given ResourceType will be available
You could be dealing with the RCPSP (Resource Constrained Project Scheduling Problem). Solution techniques range from integer programming and constraint programming to various heuristics. The technique depends the details such as planning horizon, how tasks/jobs use/share resources, how fast you need an solution schedule, etc.
see:
https://developers.google.com/optimization/scheduling/job_shop
http://www.laas.fr/files/ROC/2014-Presentations/MILP-RCPSP-PMS2014.pdf
Waiting time is defined as how long each process has to wait before it gets it's time slice.
In scheduling algorithms such as Shorted Job First and First Come First Serve, we can find that waiting time easily when we just queue up the jobs and see how long each one had to wait before it got serviced.
When it comes to Round Robin or any other preemptive algorithms, we find that long running jobs spend a little time in CPU, when they are preempted and then wait for sometime for it's turn to execute and at some point in it's turn, it executes till completion. I wanted to findout the best way to understand 'waiting time' of the jobs in such a scheduling algorithm.
I found a formula which gives waiting time as:
Waiting Time = (Final Start Time - Previous Time in CPU - Arrival Time)
But I fail to understand the reasoning for this formula. For e.g. Consider a job A which has a burst time of 30 units and round-robin happens at every 5 units. There are two more jobs B(10) and C(15).
The order in which these will be serviced would be:
0 A 5 B 10 C 15 A 20 B 25 C 30 A 35 C 40 A 45 A 50 A 55
Waiting time for A = 40 - 5 - 0
I choose 40 because, after 40 A never waits. It just gets its time slices and goes on and on.
Choose 5 because A spent in process previouly between 30 and 35.
0 is the start time.
Well, I have a doubt in this formula as why was 15 A 20 is not accounted for?
Intuitively, I unable to get how this is getting us the waiting time for A, when we are just accounting for the penultimate execution only and then subtracting the arrival time.
According to me, the waiting time for A should be:
Final Start time - (sum of all times it spend in the processing).
If this formula is wrong, why is it?
Please help clarify my understanding of this concept.
You've misunderstood what the formula means by "previous time in CPU". This actually means the same thing as what you call "sum of all times it spend in the processing". (I guess "previous time in CPU" is supposed to be short for "total time previously spent running on the CPU", where "previously" means "before the final start".)
You still need to subtract the arrival time because the process obviously wasn't waiting before it arrived. (Just in case this is unclear: The "arrival time" is the time when the job was submitted to the scheduler.) In your example, the arrival time for all processes is 0, so this doesn't make a difference there, but in the general case, the arrival time needs to be taken into account.
Edit: If you look at the example on the webpage you linked to, process P1 takes two time slices of four time units each before its final start, and its "previous time in CPU" is calculated as 8, consistent with the interpretation above.
Last waiting
value-(time quantum×(n-1))
Here n denotes the no of times a process arrives in the gantt chart.