线程管理模块
【部分内容已经过时】模块经过了重构，支持多核调度
线程管理模块的职责是完成CPU资源的管理。它建立在硬件提供的中断及上下文切换机制之上，提供线程的管理和调度功能。此模块功能相当于ucore lab4。
注意它不负责管理 线程使用的其他资源（如内存、文件），也不了解用户态和内核态的切换（由使用者构造合适的上下文来解决）。目前的设计基于单核CPU，未来扩展到多核时可能需要重新调整。
具体而言，使用者只需实现底层的上下文切换过程，即可享用内核线程的功能。此模块提供了直接操作线程的接口，如fork、exit、wait，用于实现系统调用。在此基础上，还封装了和
std::thread完全相同的上层接口，使得用户态的Rust多线程程序可以方便地迁移到内核中。此模块作为独立的crate存在，代码位于：
crate/processsrc目录结构及各文件功能如下：
.
├── lib.rs 根模块
├── processor.rs 一个CPU核的管理器
├── scheduler.rs 调度算法
├── thread.rs 实现std::thread接口
├── event_hub.rs 简单事件管理器
└── util.rs 其它工具
理论上可以在Linux用户态实现一个模拟的上下文切换，进而编写单元测试，但这个想法尚未实现。
位于
processor.rs，只有一个很简单的trait：processor.rs
pub trait Context: Debug {
/// 将当前CPU切换到另一个上下文
unsafe fn switch(&mut self, target: &mut Self);
/// 构造一个新的内核态上下文
/// 只用于实现thread::spawn
fn new_kernel(entry: extern fn(usize) -> !, arg: usize) -> Self;
}
这个上下文实际上是保存在内核栈上的寄存器和中断帧TrapFrame，切换switch过程实际就是一段保存和恢复寄存器的汇编代码。
读者可分别查看它在x86_64和RISCV32下的实现，了解具体使用方法：
- arch/x86_64/interrupt/trapframe.rs
- arch/riscv32/context.rs
为了创建一个新的线程，使用者需要分配好一个内核栈，并精心构造栈顶的初始数据，使得switch后能正确设置CPU状态。Context的构造函数需由使用者自己定义，不会在接口中体现。RustOS中实现了三种构造函数，分别用于创建内核线程、用户线程、fork已有线程。
这套接口是面向软件上下文切换设计的，如果CPU支持硬件切换上下文，可能实现会更简单。
位于
scheduler.rs，首先定义了接口：scheduler.rs
/// 调度器接口
/// 本质是一个就绪态线程的优先队列
pub trait Scheduler {
/// 添加一个就绪线程
fn insert(&mut self, pid: Pid);
/// 移除一个就绪线程
fn remove(&mut self, pid: Pid);
/// 选出下一个要执行的线程，但不移除它
fn select(&mut self) -> Option<Pid>;
/// 每隔固定时间调用此函数，更新当前线程的时间片信息
/// 返回是否该线程时间片用完，需要调度
fn tick(&mut self, current: Pid) -> bool; // need reschedule?
/// 设置线程优先级
fn set_priority(&mut self, pid: Pid, priority: u8);
}
之后提供了两个调度算法的实现：时间片轮转（RR），Stride。
位于
processor.rs，其中包含以下结构：- Status：枚举类型，保存线程状态
- Event：枚举类型，描述未来的调度事件
- WaitResult：枚举类型，作为返回值描述线程的等待状态
- Process：线程控制块
- Processor：完成实际CPU管理的主体
Processor的完整定义如下：
Processor_<T: Context, S: Scheduler>
使用时需指定T和S的实现类型，然后定义一个全局实例：
process/mod.rs
type Processor = Processor_<Context, StrideScheduler>;
// Once用来支持稍后手动初始化
// 这里的Mutex实际是一个修改后的SpinNoIrqLock
// 即在lock期间同时关闭中断的自旋锁
// 目的是防止中断时再中断，导致死锁
static PROCESSOR: Once<Mutex<Processor>> = Once::new();
// 初始化示意
fn process_init() {
PROCESSOR.call_once(|| Mutex::new(
// 构造一个实例
Processor::new(
// 当前第一个线程的Context，内容为空
unsafe { Context::new_init() },
StrideScheduler::new(5),
)
));
}
创建新线程时，首先自己构造Context，然后add：
// 定义idle线程
extern fn idle(arg: usize) -> ! {
loop {}
}
// 构造Context并添加到Processor
processor.add(Context::new_kernel(entry: idle, arg: 0));
Processor目前的设计是让【修改线程状态】和【执行线程切换】两种操作尽量分离。
具体而言，【执行线程切换】只能通过schedule函数进行，它会判断当前线程状态是否为Running，若不是，委托调度器选出下一个目标线程，执行切换，等到下次切换回来时退出schedule函数。
而其它大部分函数（除current_wait_for），只会【修改线程状态】，而不会执行线程切换。其中exit/kill/sleep/wakeup/yield_now函数，会调用set_status进行显式的状态修改；而tick函数，会根据当前时刻的调度事件，进行隐式的状态修改。
在原版ucore中，每个CPU核有一个专门的调度线程，进行线程调度时，首先切换到调度线程，然后再切换到下一个线程。而在RustOS中是没有调度线程的，源线程直接调用schedule函数切换到下一个线程，能减少一次上下文切换。这两种实现方式哪种更好，欢迎大家一起讨论。
位于
thread.rs，首先定义了ThreadSupport接口提供底层支持，然后定义了一个空结构ThreadMod<S: ThreadSupport>实现和std::thread相同的上层接口。由于这部分仅仅是在Processor外面又套了一层，因此所谓的
ThreadSupport接口只需能访问到全局Processor即可。对使用者而言，需要进行以下操作：// 首先我们已经有了一个Processor的全局实例
type Processor = Processor_<Context, StrideScheduler>;
pub static PROCESSOR: Once<Mutex<Processor>> = Once::new();
// 实现ThreadSupport接口
pub struct ThreadSupportImpl;
impl ThreadSupport for ThreadSupportImpl {
type Context = Context;
type Scheduler = StrideScheduler;
type ProcessorGuard = MutexGuard<'static, Processor>;
// 上面都是铺垫，下面才是重点
fn processor() -> Self::ProcessorGuard {
PROCESSOR.try().unwrap().lock()
}
}
// ‘实例化’ThreadMod，并假装它是一个mod
#[allow(non_camel_case_types)]
pub type thread = ThreadMod<ThreadSupportImpl>;
// 然后就可以把它当作`std::thread`来用了
use thread;
let t = thread::current();
// 然而假的毕竟是假的……
let t: thread::Thread; // Compile ERROR!
之所以用这样一种奇怪的实现方式，是为了这个需求：我希望实现一些全局静态函数，同时希望它们的底层依赖是可替换的。std::thread本身的实现方式是用条件编译，对不同系统使用不同的底层函数，然而我们这个没法这么搞。另一种可能的实现方式是用一个大宏把整个包起来，使用时再展开， 不过这样IDE就无法实时分析这部分代码了……
至于thread本身的实现，除了spawn之外都比较简单，读者可查看源码了解实现细节。
- 多核支持
Last modified 4yr ago