用户进程如何在不经过上下文切换的情况下执行系统调用?
当用户进程执行系统调用时,会调用内核进程。现在,这NOT如何导致上下文切换?由于内核进程与用户进程不同。或者我说内核例程(由系统调用调用)和用户进程属于同一进程是错误的吗?
When a user process performs a system call, a kernel process gets invoked. Now how does this NOT result in a context switch ? Since the kernel process is different from a user process . Or Am I wrong in saying that a kernel routine (invoked by system call) and user processes belong to the same process ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
“当用户进程执行系统调用时,会调用内核进程”——实际上并非如此,而是会调用内核代码。任何系统调用都将不可避免地导致保护上下文更改——环循环。这有多深取决于通话。如果调用到达环 0,则那里的内核代码可以访问所有用户和内核线程,因此那里的内核代码通常不能被描述为“进程”——需要提供内存管理/安全上下文的东西保护。通常,往返环 0 的环周期需要 2000 多个 cpu 周期(德国歌剧除外,需要三天)。无论系统调用是否导致线程上下文切换和/或进程上下文切换,这种开销都是绝对需要的。
在系统调用导致更改正在运行的线程集的情况下,将会产生线程上下文切换的额外开销,特别是如果更改需要抢占正在另一个处理器上运行的线程。
如果任何新运行的线程与被抢占的线程属于不同的进程,则进程上下文切换的开销会更大。
'When a user process performs a system call, a kernel process gets invoked' - not really, kernel code gets invoked. Any system call will inevitably result in a protection context change - a ring-cycle. How deep this gets depends on the call. If the call reaches ring 0, the kernel code there has access to all user and kernel threads, so the kernel code there cannot, in general, be described as a 'process' - something that has a memory-management/security context to provide protection. Typically, a ring-cycle to/from ring 0 takes 2000+ cpu-cycles, (except in German operas, where it takes three days). This overhead is absolutely required whether or not the system-call results in a thread context switch and/or process-context switch.
In those cases where the system call results in changing the set of running threads, there will be the extra overhead of a thread-context switch, especially if the change requires preemption of a thread that is running on another processor.
If any newly-running thread belongs to a different process than the preempted thread, there is the yet heavier overhead of a process-context switch.