1. 优先级反转问题与捐赠机制我第一次在Pintos里遇到优先级反转问题时系统直接卡死了——高优先级线程H等着低优先级线程L释放锁但L根本抢不到CPU。这种场景就像救护车被堵在卡车后面而卡车司机正在等红灯。操作系统课程里把这个现象称为优先级反转它会让实时系统完全失去可预测性。优先级捐赠机制的精妙之处在于它打破了这种死循环。当高优先级线程H需要获取被低优先级线程L持有的锁时H会把自己的优先级借给L。这就相当于给卡车司机开了警笛让它能临时获得道路优先权。具体实现时需要区分三种典型场景简单捐赠线程A优先级31持有锁线程B优先级33尝试获取该锁时A的优先级临时提升到33递归捐赠线程A持有锁1线程B持有锁2A在等锁2线程C高优先级尝试获取锁1时需要同时提升A和B的优先级多重捐赠线程A持有锁同时有多个高优先级线程B、C都在等待该锁时A应该获得这些线程中的最高优先级在Pintos的thread结构体中我们新增了三个关键字段来支持这个机制struct thread { int base_priority; // 线程的原始优先级 struct list locks; // 线程当前持有的所有锁 struct lock *lock_waiting; // 线程正在等待的锁 };2. 数据结构改造实战改造lock结构体时踩过一个坑最初只记录了当前持有者的优先级没考虑多重捐赠的情况。后来增加了max_priority字段用来记录所有等待线程中的最高优先级struct lock { struct list_elem elem; // 用于优先级捐赠列表 int max_priority; // 等待线程中的最高优先级 // ...其他原有字段 };初始化线程时要特别注意锁列表的初始化我在thread_init()函数里加了这两行t-base_priority priority; list_init(t-locks);实测中发现一个易错点在lock_acquire()中获取锁之前必须先处理优先级捐赠逻辑。正确的执行顺序应该是检查当前线程优先级是否高于锁持有者如果需要捐赠递归更新所有相关线程优先级执行实际的锁获取操作将锁添加到线程的持有锁列表3. 核心算法实现细节优先级捐赠的核心逻辑在thread_donate_priority()函数中实现。这里有个优化技巧不是直接修改线程优先级而是通过锁的max_priority来间接控制void thread_donate_priority(struct thread *t, int new_priority) { if (new_priority t-priority) return; t-priority new_priority; if (t-status THREAD_READY) { // 如果线程在就绪队列中需要重新排序 list_remove(t-elem); list_insert_ordered(ready_list, t-elem, thread_less_priority, NULL); } }处理递归捐赠时我写了个notify_father()辅助函数。它会沿着锁的持有链向上追溯直到遇到没有更高优先级需求的线程static void notify_father(struct thread *t) { if (t-lock_waiting NULL) return; struct thread *holder t-lock_waiting-holder; int max_priority list_max(t-lock_waiting-waiters, thread_priority_less, NULL); if (max_priority holder-priority) { thread_donate_priority(holder, max_priority); notify_father(holder); // 递归处理 } }释放锁时的处理同样关键。在lock_release()中需要恢复锁持有者的原始优先级检查是否还有其他锁在被持有如果没有锁了完全恢复base_priority否则取剩余锁中的最高优先级4. 测试与调试经验priority-donate-one测试用例最能验证简单捐赠场景。我调试时发现一个典型错误忘记在释放锁时更新ready_list的顺序。这会导致调度器仍然按旧优先级选择线程。对于递归捐赠测试priority-donate-nest建议在代码中加入调试输出printf(Thread %s donating to %s (new prio: %d)\n, thread_current()-name, holder-name, new_priority);遇到最棘手的bug是在多重捐赠场景下当多个高优先级线程等待同一个锁时最初实现只记录了最后一个捐赠者的优先级。解决方案是在lock结构体中维护一个捐赠者优先级列表而不是单个值。5. 性能优化技巧在实现优先级队列时直接使用Pintos提供的list_insert_ordered()虽然方便但在高频操作时性能较差。我最终优化为保持ready_list始终有序只在thread_yield()时执行全列表排序其他时候用二分查找确定插入位置对于递归深度问题设置了一个最大捐赠深度限制实测8层足够。超过该深度时会打印警告但仍继续执行避免栈溢出。6. 与其他模块的交互优先级捐赠会影响定时器唤醒策略。在timer_sleep()的实现中需要特别注意被捐赠优先级的线程唤醒后应该保持捐赠优先级直到释放所有锁。与信号量的交互也是个坑点。最初我的sema_up()没有考虑优先级导致高优先级线程可能无法立即被唤醒。修正后的实现void sema_up(struct semaphore *sema) { enum intr_level old_level intr_disable(); if (!list_empty(sema-waiters)) { // 按优先级排序后唤醒第一个 list_sort(sema-waiters, thread_priority_less, NULL); thread_unblock(list_entry(list_pop_front(sema-waiters), struct thread, elem)); } intr_set_level(old_level); }7. 真实项目中的教训在课程项目中我们组最初尝试用一个全局捐赠表来记录所有优先级关系结果发现锁竞争太严重。后来改为每个锁维护自己的捐赠列表性能提升了近3倍。另一个经验是在thread_set_priority()实现中必须区分基础优先级和捐赠优先级。直接覆盖当前优先级会导致捐赠失效。正确做法是void thread_set_priority(int new_priority) { thread_current()-base_priority new_priority; if (list_empty(thread_current()-locks)) { // 没有锁时才允许直接修改当前优先级 thread_current()-priority new_priority; } thread_yield_if_should(); }