如果系统调用与过程调用一样快，是否会使内核级线程明显优于用户级线程? [英] Would it makes the kernel level thread clearly preferable to user level thread if system calls is as fast as procedure calls?

问题描述

一些网络搜索结果告诉我内核级线程的唯一缺陷是其管理(创建，切换，终止等)的速度较慢.看来如果内核级线程上的操作全部通过系统调用完成，那么我的问题的答案将是正确的.但是，我进行了很多搜索，以查找内核级线程的管理是否全部通过系统调用进行，但一无所获.而且我总是有一种直觉，即这样的管理应该由OS自动完成，因为只有OS知道哪个线程适合在特定时间运行.因此，程序员似乎不可能编写一些显式的系统调用来管理线程.我对任何想法都很感激.

Some web searching results told me that the only deficiency of kernel-level thread is the slow speed of its management(create, switch, terminate, etc.). It seems that if the operation on the kernel-level thread is all through system calls, the answer to my question will be true. However, I've searched a lot to find whether the management of kernel-level thread is all through system call but find nothing. And I always have an instinct that such management should be done by the OS automatically because only OS knows which thread would be suitable to run at a specific time. So it seems impossible for programmers to write some explicit system calls to manage threads. I'm appreciative of any ideas.

推荐答案

一些网络搜索结果告诉我，内核级线程的唯一不足是其管理(创建，切换，终止等)的速度较慢.

Some web searching results told me that the only deficiency of kernel-level thread is the slow speed of its management(create, switch, terminate, etc.).

这不是那么简单.要理解，请考虑导致任务切换的原因.这是(部分)列表:

It's not that simple. To understand, think about what causes task switches. Here's a (partial) list:

• 设备告诉设备驱动程序，操作已完成(一些数据已到达等)，导致正在等待该操作的线程解除阻塞，然后抢占了当前正在运行的线程.对于这种情况，当您发现需要进行任务切换时，您正在运行内核代码，因此内核任务切换速度更快.

• a device told a device driver that an operation completed (some data arrived, etc) causing a thread that was waiting for the operation to unblock and then preempt the currently running thread. For this case you're running kernel code when you find out that a task switch is needed, so kernel task switching is faster.

足够的时间过去了；要么导致时间片结束"任务切换，要么导致睡眠线程取消阻止并抢占.对于这种情况，当您发现需要进行任务切换时，您正在运行内核代码，因此内核任务切换速度更快.

enough time passed; either causing an "end of time slice" task switch, or causing a sleeping thread to unblock and preempt. For this case you're running kernel code when you find out that a task switch is needed, so kernel task switching is faster.

线程访问了当前无法访问的虚拟内存，从而触发了内核的页面错误处理程序，该处理程序发现当前任务必须等待内核从交换空间或文件中获取数据(如果虚拟内存是内存映射文件的一部分)，或者必须等待内核通过将其他页面发送到交换空间来释放RAM(如果虚拟内存涉及某种写入时复制")；导致任务切换，因为当前正在运行的任务无法继续.对于这种情况，当您发现需要进行任务切换时，您正在运行内核代码，因此内核任务切换速度更快.

the thread accessed virtual memory that isn't currently accessible, triggering the kernel's page fault handler which finds out that the current task has to wait while the kernel fetches data from from swap space or from a file (if the virtual memory is part of a memory mapped file), or has to wait for kernel to free up RAM by sending other pages to swap space (if virtual memory was involved in some kind of "copy on write"); causing a task switch because the currently running task can't continue. For this case you're running kernel code when you find out that a task switch is needed, so kernel task switching is faster.

正在创建一个新进程，其初始线程优先于当前正在运行的线程.对于这种情况，当您发现需要进行任务切换时，您正在运行内核代码，因此内核任务切换速度更快.

a new process is being created, and its initial thread preempts the currently running thread. For this case you're running kernel code when you find out that a task switch is needed, so kernel task switching is faster.

当前正在运行的线程要求内核对文件执行某些操作，并且内核出现"VFS高速缓存未命中"，从而阻止了在没有任何任务切换的情况下执行请求.对于这种情况，当您发现需要进行任务切换时，您正在运行内核代码，因此内核任务切换速度更快.

the currently running thread asked kernel to do something with a file and kernel got "VFS cache miss" that prevents the request from being performed without any task switches. For this case you're running kernel code when you find out that a task switch is needed, so kernel task switching is faster.

当前正在运行的线程释放互斥锁或发送一些数据(例如，使用管道或套接字)；导致属于不同进程的线程取消阻塞并抢占.对于这种情况，当您发现需要进行任务切换时，您正在运行内核代码，因此内核任务切换速度更快.

the currently running thread releases a mutex or sends some data (e.g. using a pipe or socket); causing a thread that belongs to a different process to unblock and preempt. For this case you're running kernel code when you find out that a task switch is needed, so kernel task switching is faster.

当前正在运行的线程释放互斥锁或发送一些数据(例如，使用管道或套接字)；导致属于同一进程的线程取消阻塞并抢占.对于这种情况，您在发现需要进行任务切换时正在运行用户空间代码，因此从理论上讲，用户空间任务切换速度更快，但实际上，它很容易表明设计不良(也可以使用)很多线程和/或太多的锁争用).

the currently running thread releases a mutex or sends some data (e.g. using a pipe or socket); causing a thread that belongs to the same process to unblock and preempt. For this case you're running user-space code when you find out that a task switch is needed, so in theory user-space task switching is faster, but in practice it can just as easily be an indicator of poor design (using too many threads and/or far too much lock contention).

正在为同一进程创建一个新线程；新线程将抢占当前正在运行的线程.对于这种情况，您在发现需要进行任务切换时正在运行用户空间代码，因此在用户空间中，任务切换更快.但是只有在不通知内核的情况下(例如，使诸如"top"之类的实用程序才能正确显示线程的详细信息)-如果无论如何都通知了内核，则任务切换发生的位置不会有太大的不同.

a new thread is being created for the same process; and the new thread preempts the currently running thread. For this case you're running user-space code when you find out that a task switch is needed, so in user-space task switching is faster; but only if kernel isn't informed (e.g. so that utilities like "top" can properly display details for threads) - if kernel is informed anyway then it doesn't make much difference where the task switch happens.

对于大多数软件(使用的线程不多)；在内核中执行任务切换更快.当然，它也(希望)与性能无关(因为与执行其他工作相比，切换任务所花费的时间应该很小).

For most software (which doesn't use very many threads); doing task switches in the kernel is faster. Of course it's also (hopefully) fairly irrelevant for performance (because time spent switching tasks should be tiny compared to time spend doing other work).

而且我总是有一种直觉，即这种管理应该由OS自动完成，因为只有OS知道哪个线程适合在特定时间运行.

And I always have an instinct that such management should be done by the OS automatically because only OS knows which thread would be suitable to run at a specific time.

是；但可能不是您想的原因.

Yes; but possibly not for the reason you think.

用户空间线程化的另一个问题(除了使大多数任务切换变慢之外)是，它不能支持全局线程优先级，而不会成为严重的安全灾难.具体来说;进程无法知道其自己的线程的优先级是否高于属于不同进程的线程的优先级(除非它具有有关整个OS的所有线程的信息，即不应该信任普通进程的信息) ;因此，在有重要工作要做(对于另一个进程)时，用户空间线程处理会浪费CPU时间在进行不重要的工作(对于一个进程).

Another problem with user-space threading (besides making most task switches slower) is that it can't support global thread priorities without becoming a severe security disaster. Specifically; a process can't know if its own thread is higher or lower priority than a thread belonging to a different process (unless it has information about all threads for the entire OS, which is information that normal processes shouldn't be trusted to have); so user-space threading leads to wasting CPU time doing unimportant work (for one process) when there's important work to do (for a different process).

用户空间线程处理的另一个问题是(对于某些CPU-例如大多数80x86 CPU)CPU不是独立的，并且调度可能涉及电源管理决策.举些例子;大多数80x86 CPU具有超线程(其中一个内核由2个逻辑处理器共享)，其中智能调度程序可能会说内核中的一个逻辑处理器正在运行高优先级/重要线程，因此同一内核中的另一个逻辑处理器不应运行低优先级/无关紧要的线程，因为这会使重要的工作变慢"；大多数80x86 CPU具有涡轮增压"功能(类似的不要让低优先级线程破坏高优先级线程的涡轮增压/性能"的可能性)；而且大多数CPU都具有热量管理功能(调度程序可能会说嘿，这些线程都是低优先级的，因此让我们降低CPU的频率，以便它冷却下来，并在优先级较高/更重要的工作时可以更快地运行(具有更大的散热空间)).去做！").

Another problem with user-space threading is that (for some CPUs - e.g. most 80x86 CPUs) the CPUs are not independent, and there may be power management decisions involved with scheduling. For examples; most 80x86 CPUs have hyper-threading (where a core is shared by 2 logical processors), where a smart scheduler may say "one logical processor in the core is running a high priority/important thread, so the other logical processor in the same core should not run a low priority/unimportant thread because that would make the important work slower"; most 80x86 CPUs have "turbo boost" (with similar "don't let low priority threads ruin the turbo-boost/performance of high priority thread" possibilities); and most CPUs have thermal management (where scheduler might say "Hey, these threads are all low priority, so let's underclock the CPU so that it cools down and can go faster later (has more thermal headroom) when there's high priority/more important work to do!").

如果系统调用与过程调用一样快，是否会使内核级线程明显优于用户级线程?

Would it makes the kernel level thread clearly preferable to user level thread if system calls is as fast as procedure calls?

如果系统调用与普通过程调用一样快，那么用户空间线程和内核线程之间的性能差异将消失(但用户空间线程的所有其他问题将保留).但是，系统调用之所以比普通过程调用慢，是因为它们经过了一种隔离屏障"(将内核代码和数据与恶意用户空间代码隔离开).因此，要使系统调用与常规过程调用一样快，就必须摆脱隔离(有效地将内核转变为一种可以动态链接的全局共享库")，但是如果没有这种隔离，您将拥有一个极端安全灾难.换一种说法;为了希望获得可接受的安全性，系统调用必须比正常过程调用慢.

If system calls were as fast as normal procedure calls, then the performance differences between user-space threading and kernel threading would disappear (but all the other problems with user-space threading would remain). However, the reason why system calls are slower than normal procedure calls is that they pass through a kind of "isolation barrier" (that isolates kernel's code and data from malicious user-space code); so to make system calls as fast as normal procedure calls you'd have to get rid of the isolation (effectively turning the kernel into a kind of "global shared library" that can be dynamically linked) but without that isolation you'll have an extreme security disaster. In other words; to have any hope of achieving acceptable security, system calls must be slower than normal procedure calls.

这篇关于如果系统调用与过程调用一样快，是否会使内核级线程明显优于用户级线程?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！