问题标签 [context-switching]

所以我想知道的是，当线程调度程序执行上下文切换时，CPU 是如何中断的，以便完成切换到不同进程的任务？当新的上下文加载到 CPU 上时，CPU 是否会暂停或进入睡眠模式？

我在跑步 ：）

永远（直到我向程序发送 KeyboardInterrupt 信号），
但是当我取消注释// printf("done:%d\n", done);，重新编译并运行它时，它只会打印两次，打印done: 1然后返回。
我是 ucontext.h 的新手，我对这段代码的工作方式以及为什么单个 printf 会改变代码的整个行为感到非常困惑，如果你用它替换printf它done++;会做同样的事情，但如果你用它替换done = 2;它确实不会影响任何事情和工作，因为我们printf首先评论过。
谁能解释一下：
为什么这段代码会这样，背后的逻辑是什么？
对不起我的英语不好，
非常感谢。

网上没有很多关于这个问题的详细信息，但希望那里的人可能有线索。我知道调度程序的工作是确定（选择）下一个要运行的进程，但是调度程序如何发现？

我正在研究 Java 多线程并尝试检查多线程的性能。我正在尝试检查多线程是否比单线程更好。所以，我写了一个总和限制的代码。当限制变大时，它按我的预期工作（多线程比单线程快），但当限制像 100000L 一样小时却没有。这是由于上下文切换吗？下面的代码是否适合检查多线程的性能？

我对上下文切换有两个主要疑问，

1. 在遵循循环调度的系统中，如果一个进程在时间片完成之前由于其完成而被终止，是否会发生上下文切换？

2. 上下文切换是否也发生在非抢占式调度算法中（即基本上在基于多道程序的操作系统中）。

谢谢！

为了减轻内存泄漏，我们在运行在不同线程上的内部类中保留活动的弱引用。我们检查weakreference.get() 是否为非空，然后再继续。如果当我们检查weakreference.get() 为非空但发生垃圾回收时，我们是否需要一次又一次地检查引用是否为非空，或者我是否遗漏了什么？

在这里，我有一个类信号量、等待和信号方法以及其他方法的实现。我的问题是，在查看等待方法时，当我们在该临界区阻塞当前线程时，何时释放等待方法内部的锁？我们可以看到阻塞方法是通过将当前线程放入阻塞队列，并从就绪队列中获取一些其他线程并发生上下文切换来实现的。如果发生上下文切换，则阻塞线程的上下文将保存在 ; 在 block() 方法之后，这意味着后面的行 (unlock()) 没有执行并且上下文被切换。因此，被阻塞的线程永远不会释放锁，还是我错过了什么？那么当我们在临界区切换上下文时，锁是如何释放的呢？这是实现： 类信号量的实现和类信号量的实现续 注意setContext方法和resume是通过setjmp和longjmp方法实现的。

在上下文切换期间，内核保存当前进程（process1）的状态并将另一个进程（process2）的状态恢复到CPU（使用process2之前的值加载各种寄存器）。

内核在换出进程1时保存了哪个内存区域？它是在 process1 的堆栈区域还是在内核本身的某个地方？提前致谢。

任何人都可以从堆栈的角度解释基于手臂的汇编代码吗？特别是在调用“main”、“save_context”和“resume”部分之前的“reset_handler”的堆栈视图？（请注意，我知道代码在做什么，但我无法理解或想象代码运行时堆栈的外观或行为方式）。