multithreading - 线程上下文切换和进程上下文切换的区别

Question

我知道 here ，这个问题有一个解释。但我对一些观点有点困惑-:

让我拥有属于进程 P1 的线程 T(1-a) 和 T(1-b) 以及属于进程 P2 的线程 T(2-a) 和 T(2-b)。

现在我的问题是-:

线程 T(1-a) 想要对线程 T(1-b) 进行上下文切换。根据 this回答，

Both types(process Context switch and thread context switch) involve handing control over to the operating system kernel to perform the context switch(i am mainly talking about thread context switch).

怀疑

if T(1-a) and T(1-b) are user level threads,Kernel won't be able to distinguish T(1-a) and T(1-b),then how context switch will be done?

让所有线程 T(1-a)、T(1-b)、T(2-a) 和 T(2-b) 都是内核级线程，如果线程 T(1-a) 想要上下文切换到 T( 2-b)。

怀疑

won't the cost/dealy will be same as that of process context switch as not only virtual memory space gets changed but also TLB gets flushed??

Answer 1

考虑这个的方式是用户线程和内核线程是两种完全不同的动物。

在该术语的正常和习惯含义下，用户线程中没有上下文切换。

Both types(process Context switch and thread context switch) involve handing control over to the operating system kernel to perform the context switch(i am mainly talking about thread context switch).

我看到你的困惑。首先，这里描述的内容仅适用于内核线程。其次，(这个问题显然是措辞的结果而不是整体消息)，在内核线程中，没有“进程上下文切换”，只有“线程上下文切换”。

在没有线程的旧时代，调度的变化意味着进程上下文的变化。执行此操作的硬件指令具有诸如 Load Process Context 和 Save Process Context 之类的名称。但是在调度线程(内核线程)的操作系统中，我们留下了这个不再精确的旧术语。 (这是解释操作系统时很多地方都会出现的问题)。

if T(1-a) and T(1-b) are user level threads,Kernel won't be able to distinguish T(1-a) and T(1-b),then how context switch will be done?

如果它们是用户级线程，内核不会知道或关心它们。它们之间的切换由用户库处理。 “线程”的切换不是上下文切换。

won't the cost/dealy will be same as that of process context switch as not only virtual memory space gets changed but also TLB gets flushed??

希望操作系统足够聪明，知道在同一进程中的线程之间切换时不刷新内存缓存。

我相信学术界需要放弃内核/用户线程(甚至更糟的是，一对一、多对一和多对多 [yuk])结构。代替他们，我建议使用这些术语

“真实线程”和“模拟线程”。