Editing Scheduling (computing) (section)

==Goals==
A scheduler may aim at one or more goals, for example:

* <!-- throughput -->maximizing ''[[throughput]]'' (the total amount of work completed per time unit); 
* <!-- wait time -->minimizing  ''[[Computer performance#Response time|wait time]]'' (time from work becoming ready until the first point it begins execution); 
* <!-- response_time/latency for batch systems -->minimizing ''[[latency (engineering)|latency]]'' or ''[[Response time (technology)|response time]]'' (time from work becoming ready until it is finished in case of batch activity,<ref name="liu1973">{{Cite journal
  | first1 = Liu
  | last1 = C. L. 
  | first2 = Layland
  | last2 = James W.
  | title = Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment
  | journal = Journal of the ACM
  | volume = 20
  | issue = 1
  | pages = 46–61
  | publisher = ACM
  | date = January 1973
  | quote = We define the response time of a request for a certain task to be the time span between the request and the end of the response to that request. 
  | doi = 10.1145/321738.321743| s2cid = 207669821 
 | doi-access = free
  }}
</ref><ref name="kleinrock1976">{{cite book
  | last = Kleinrock
  | first = Leonard
  | title = Queueing Systems, Vol. 2: Computer Applications
  | publisher = Wiley-Interscience
  | url = https://archive.org/details/queueingsystems00klei/page/171
  | isbn = 047149111X
  | quote = For a customer requiring x sec of service, his response time will equal his service time x plus his waiting time.
  | edition = 1
  | page = [https://archive.org/details/queueingsystems00klei/page/171 171]
  | year = 1976
  }}
</ref><ref name="feitelson2014">{{cite book
  | last = Feitelson
  | first = Dror G.
  | title = Workload Modeling for Computer Systems Performance Evaluation
  | publisher = Cambridge University Press
  | url = http://www.cs.huji.ac.il/~feit/wlmod/
  | isbn = 9781107078239
  | access-date = 2015-10-17
  | quote = if we denote the time that a job waits in the queue by t<sub>w</sub>, and the time it actually runs by t<sub>r</sub>, then the response time is r = t<sub>w</sub> + t<sub>r</sub>.
  | at = Section 8.4 (Page 422) in Version 1.03 of the freely available manuscript
  | year = 2015}}
</ref><!-- response_time/latency for interactive systems --> or until the system responds and hands the first output to the user in case of interactive activity);<ref name="silberschatz2012">{{cite book
  | last1 = Silberschatz
  | first1 = Abraham
  | last2 = Galvin
  | first2 = Peter Baer
  | last3 = Gagne
  | first3 = Greg
  | title = Operating System Concepts
  | publisher = Wiley Publishing
  | isbn = 978-0470128725
  | quote = In an interactive system, turnaround time may not be the best criterion. Often, a process can produce some output fairly early and can continue computing new results while previous results are being output to the user. Thus, another measure is the time from the submission of a request until the first response is produced. This measure, called response time, is the time it takes to start responding, not the time it takes to output the response.
  | edition = 9
  | page = 187
  | year = 2012}}</ref>
* <!-- fairness -->maximizing ''fairness'' (equal CPU time to each process, or more generally appropriate times according to the priority and workload of each process).

In practice, these goals often conflict (e.g. throughput versus latency), thus a scheduler will implement a suitable compromise.  Preference is measured by any one of the concerns mentioned above, depending upon the user's needs and objectives.

In [[real-time computing|real-time]] environments, such as [[embedded system]]s for [[automatic control]] in industry (for example [[robotics]]), the scheduler also must ensure that processes can meet [[time limit|deadlines]]; this is crucial for keeping the system stable. Scheduled tasks can also be distributed to remote devices across a network and [[device Management|managed]] through an administrative back end.