进程调度术语困境 [英] Process Scheduling Terminology dilema

问题描述

我理解一个进程是一个正在执行的代码。如果它正在执行，那么它必须保存到cpu或任何其他资源。现在，如果它已经持有其中一个资源那么为什么需要进程调度，因为它正在部分执行？

解决方案

这个问题非常模糊，但是，最有可能的是，这意味着您的问题与理解多处理有关，在现代系统中，这也与多线程有关。



基本思路是：考虑你有很多进程，每个进程运行一个线程或多个线程，只有一个CPU只有一个CPU核心。这种情况的普遍化是拥有更多的CPU或核心，但它不会增加对基础知识的理解。所有这些进程的线程仍然是并行执行的。这是通过为每个线程提供一些资源来实现的，首先是一些内存，基本上是堆栈（请参阅下面的参考资料），CPU和其他资源。线程可以独占使用这些资源，但是，为了让其他线程独立工作，可以中断，关闭当前线程，并将资源提供给其他线程。虽然线程保留了它们的堆栈和其他内存的一部分（在现代系统上，由于称为虚拟内存的架构的独立部分，这比这更复杂，但是这种机制对于线程而言是完全透明的一个进程，所以你可以认为分配的内存只属于每个进程），特别是CPU及其寄存器。为了避免线程之间的干扰，在线程关闭时存储CPU及其所有寄存器的状态，并完全恢复，然后切换相同的线程再次执行。在许多CPU中，这种线程切换由其指令集全面支持，并且由于这种实现的硬件性质，非常快。



在上面，这个机制，上面描述的线程切换可能由于不同的原因。它可以被某些应用程序代码直接调用（这不是一个调用，因为没有返回）。这种机制用于协作式多任务处理。在现代系统中，使用抢先式多任务。在这种情况下，通过定时器中断，通常在非实时系统中的硬件中断上调用线程切换机制。每个线程仅在某个时间片期间工作，然后被切换出来。据说是先发制人。请注意，在实时系统中，此机制可以是高度专业化的。 （让我们说这个话题远远超出了这个问题的主题。）



只有在上面所有的上面，调度是必需的。上述机制非常低级，但调度程序是最高级别的代码。它只是拥有系统中所有线程的集合，并且必须回答这个问题：谁是下一个？。实际上，当涉及上述 preemption 时，该线程不会被某些其他应用程序的线程抢占。实际上，它被一些代码（在现代系统中，OS 内核中的代码）抢占了，它最终调用了调度程序，得到了这个问题的答案，然后根据它转换到其他一些线程。 。实际上，回答这个谁的下一个问题的算法可能非常复杂并且包含许多因素：实际执行时间，等待其时间片的其他线程的状态和属性，等待的实际时间（在特殊的中等待状态与线程同步原语的使用有关，进程和线程的优先级等等。



请参阅：

http://en.wikipedia.org/wiki/Multiprocessing [ ^ ]，

http://en.wikipedia.org/wiki/Multithreading_%28software%29#Multithreading [ ^ ]，

HTTP： //en.wikipedia.org/wiki/Call_stack [ ^ ]，

http://en.wikipedia.org/wiki/Cooperative_multitasking [ ^ ]，

http://en.wikipedia.org/wiki/Preemptive_multitasking#Preemptive_multitasking [ ^ ]，

http://en.wikipedia.org/wiki/Time_slice#Time_slice [ ^ ]，

HTTP：//en.w ikipedia.org/wiki/Scheduling_%28computing%29 [ ^ ]，

http://en.wikipedia.org/wiki/OS_kernel [ ^ ]，

http://en.wikipedia.org/wiki/Real-time_computing [ ^ ]。

-SA

I understand a process is a code under execution. If it is executing then it must hold to a cpu or any other resource. Now if it is already holding to one of the resources then why process scheduling is required as it is being executed though partly?

解决方案

The question is very vague, but, most likely, it means that your problem is related to understanding of multiprocessing, which is, in modern systems, is also related to multithreading.

The basic idea is: consider you have many processes each running either one thread or more threads, and only one CPU with only one CPU core. The generalization of this situation is having more CPUs or cores, but it won't add much to understanding of the basics. The threads of all those processes are still executed in parallel. This is achieved by giving each thread some resources, first of all, some memory, essentially, the stack (please see the reference below), CPU and other resources. The thread can use those resources exclusively, but, to let other threads work independently, the current thread can be interrupted, switched off, and the resources will be given to some other thread. While threads retain they stack and part of other memory (on modern systems, this is way more complex than that because of the independent part of architecture called virtual memory, but this mechanism is fully transparent for a thread and a process, so you can consider that allocated memory belongs to each process exclusively), and, notably, the CPU and its registers. To avoid interference between threads, the states of the CPU and all its registers is stored when a thread is switched off, and fully restored then the same thread is switched for execution again. In many CPUs this thread switching is comprehensively supported by its instruction-set and, due it hardware nature of such implementations, is very fast.

In top it this mechanism, thread switching described above can be causes by different reasons. It can be "called" directly by some application code (this is not exactly a "call", because there is no return). Such mechanisms are used in cooperative multitasking. In modern system, preemptive multitasking is used. In this case, the thread switching mechanism is invoked on hardware interrupts, typically, in non-realtime system, by the timer interrupt. Each thread works exclusively during some time slice and then is switched out. It is said to be preempted. Note that in realtime systems this mechanism can be highly specialized. (Let's say this topic is well beyond the topic of this question.)

And only on top all of the above, scheduling is required. The mechanisms described above are very low-level, but the scheduler is the most high-level code. It simply have the collection of all the threads in the system and has to answer the question: "who's next?". Actually, when it comes to preemption described above, the thread is not preempted by the thread of some other application. In fact, it is preempted by some code (in modern system, the code in the OS kernel) which eventually calls the scheduler, get the answer to this question and then switches to some other thread according to it. Actually, the algorithm of answering to this "who's next question" can be very complex and include many factors: actual time of execution, states and properties of other threads waiting for their time slices, actual times of waiting (in a special wait state related to the use of thread synchronization primitive or not), priorities of processes and threads, and so on.

Please see:
http://en.wikipedia.org/wiki/Multiprocessing[^],
http://en.wikipedia.org/wiki/Multithreading_%28software%29#Multithreading[^],
http://en.wikipedia.org/wiki/Call_stack[^],
http://en.wikipedia.org/wiki/Cooperative_multitasking[^],
http://en.wikipedia.org/wiki/Preemptive_multitasking#Preemptive_multitasking[^],
http://en.wikipedia.org/wiki/Time_slice#Time_slice[^],
http://en.wikipedia.org/wiki/Scheduling_%28computing%29[^],
http://en.wikipedia.org/wiki/OS_kernel[^],
http://en.wikipedia.org/wiki/Real-time_computing[^].

—SA

这篇关于进程调度术语困境的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！