|
1 | 1 |
|
2 | 2 | \pagebreak |
3 | | -\pdfbookmark[0]{process manipulation, program execution}{procesy} |
| 3 | +\pdfbookmark[0]{process manipulation, program execution}{processes} |
4 | 4 |
|
5 | 5 | \begin{slide} |
6 | 6 | \sltitle{Contents} |
|
244 | 244 | \item \emsl{The premise of preemptive planning are periodic timer interrupts} |
245 | 245 | which take away the CPU from the running process and pass on the CPU |
246 | 246 | to the kernel (scheduler is activated). |
247 | | -\item The other variant is non-preemtive (cooperative) planning, where process |
| 247 | +\item The other variant is non-preemptive (cooperative) planning, where process |
248 | 248 | keeps running, until it gives up the CPU, i.e. until it calls such system call, |
249 | 249 | that switches the context to different process. The downside of cooperative |
250 | 250 | planning is that one process can block the CPU and other processes forever. |
251 | 251 | \item Unix uses only preemptive planning for user processes. |
252 | 252 | \item Traditional (historical) UNIX \emsl{kernel} uses cooperative planning, |
253 | 253 | i.e. process running in kernel mode is not switched until it gives up the CPU |
254 | 254 | by itself. |
255 | | -\emsl{Modern Unix kernels are preemtive} -- mainly because of real-time |
| 255 | +\emsl{Modern Unix kernels are preemptive} -- mainly because of real-time |
256 | 256 | systems; where it is necessary to have the possibility to remove a CPU from |
257 | 257 | a running process immediately, and not waiting until it returns from a kernel |
258 | | -mode or enters sleep by itself. Note that UNIX was preemtive from its very |
| 258 | +mode or enters sleep by itself. Note that UNIX was preemptive from its very |
259 | 259 | beginning but its kernel was non-preemptive in the beginning. |
260 | 260 | \item With a preemptive planning processes can be interrupted at any time and |
261 | 261 | the CPU given to another process. Therefore a process can never be sure |
|
0 commit comments