yield()是明确的调度请求信号，其效果取决于系统是否启用可剥夺调度及调度器是否执行切换；在非剥夺式系统中无效，在FreeRTOS等实时系统中通常立即生效，在Linux中仅移至就绪队列末尾，在xv6中则强制重调度。
yield() 不是“让出 CPU”的魔法开关，它是一次明确的调度请求信号，其效果完全取决于当前系统是否启用可剥夺调度、以及调度器是否在该时刻真正执行了任务切换。
可剥夺调度：yield() 起作用的前提
yield() 能否触发切换，首先看内核是否支持可剥夺（Preemptive）调度。在非剥夺式系统中，即使调用了 yield()，当前任务也会继续运行直到自然结束或阻塞；只有在可剥夺型系统里，yield() 才有机会把控制权交出去。
- FreeRTOS、uC/OS-III、VxWorks 等实时操作系统默认启用可剥夺调度，yield() 通常立即生效
- Linux 默认使用 CFS 调度器，属于抢占式，但 yield() 在用户态调用的是 sched_yield()，它只是将当前线程移至就绪队列末尾，不保证立刻让出 CPU——是否切换取决于其他就绪线程的优先级和负载
- xv6 的 yield() 显式调用 sched()，强制进入调度循环，属于“主动让出 + 立即重调度”，是典型的可剥夺语义实现
yield() 的真实位置：不是指令，而是上下文切换的起点
从物理角度看，yield() 本身没有“内存地址”或“CPU 指令位置”，它是一段用户或内核函数调用，真正起作用的是它后续触发的一系列动作：
- 保存当前任务的寄存器状态（PC、SP、通用寄存器等）到其任务控制块（TCB）中
- 更新任务状态：从 RUNNING → RUNNABLE
- 调用调度器核心逻辑（如 OS_Sched() 或 pick_next_task），扫描就绪队列，选出最高优先级就绪任务
- 恢复目标任务的寄存器状态，跳转至其上次被中断的指令地址继续执行
这个过程就是一次完整的上下文切换（context switch），而 yield() 就是这场切换的发起者——它站在软中断返回前、任务状态变更后、调度决策开始前的那个精确节点上。
为什么你写的 yield() 常常“没反应”？
常见失效场景不是 yield() 写错了，而是环境不匹配：
- 在单线程程序中调用 yield()：没有其他就绪任务，调度器选回自己，等于什么都没做
- 在协程库（如 libco、goroutine）中误用系统 yield()：协程调度在用户态，系统级 yield() 对其无效
- 在中断服务程序（ISR）中调用 yield()：多数 RTOS 禁止在 ISR 中直接调度，需改用 OSxxxPost() 触发任务唤醒再由调度器自动响应
- 任务优先级设置不当：当前任务已是就绪队列中最高优先级，yield() 后仍被选中
动手验证：在 xv6 中定位 yield() 的物理路径
以 xv6 为例，可以顺着代码链路看到 yield() 如何落地为一次真实切换：
- 用户程序调用 yield() → 进入 syscall → 调用 sys_yield()
- sys_yield() → 调用 yield()（kernel/proc.c）→ 修改 p->state = RUNNABLE → 调用 sched()
- sched() → 检查 islocked、切换栈、调用 swtch() → 实际汇编层保存/恢复寄存器
- swtch() 返回后，scheduler() 循环查找下一个 p->state == RUNNABLE 的进程并加载其上下文
整个链条中，yield() 是第一个软件可见的调度锚点，而 swtch() 是最后一步硬件可见的上下文搬运工。
