信号量优先级反转问题记录（总是遗忘）

1.信号量

信号量一般用于线程间同步&＃xff0c;多个线程获取一个共享资源时&＃xff0c;该资源信号量的count值不小于0时&＃xff0c;取得count的线程皆可访问共享资源&＃xff08;类似于流量QOS中的令牌桶\通行证&＃xff09;。当count值小于0时&＃xff0c;获取该资源的线程阻塞等待其他线程释放资源count值重新大于0&＃xff08;类似于有空余令牌桶\通行证释放出来了&＃xff09;.

2.优先级反转问题

假设有三个线程优先级从高到低&＃xff1a;A (共享资源XXX) B(普通线程不竞争资源) C(共享资源XXX)。

按照正常的线程执行流优先级执行的结果是&＃xff1a;A先执行完, B居中执行完, C最后执行完.

但现实中存在这么一个现象&＃xff1a;

&＃xff08;1&＃xff09;C执行时先使用共享资源XXX&＃xff0c;获取信号量正在运行&＃xff1b;

&＃xff08;2&＃xff09;此时B投入ready队列准备运行&＃xff0c;下一个时钟中断调度时&＃xff0c;B优先级高于C&＃xff0c;先调度执行B中.C被放在ready队列.

&＃xff08;3&＃xff09;A投入ready队列准备运行&＃xff0c;下一个时钟中断调度时&＃xff0c;B被调度放入ready队列&＃xff0c;A调度运行&＃xff0c;但此时A运行时需要获取共享资源XXX&＃xff0c;而共享资源XXX被C占用&＃xff0c;A因为没有共享资源XXX的“通行证”而被迫放入共享资源XXX的阻塞队列而放弃CPU。

&＃xff08;4&＃xff09;到此处&＃xff0c;A被阻塞&＃xff0c;B在ready队列&＃xff0c;C在ready队列&＃xff0c;CPU空着

继续调度,CPU优先运行高优先级B线程&＃xff0c;直到执行完.接着执行C线程,C访问完共享资源XXX释放“通行证”&＃xff0c;A被唤醒放入ready队列.

&＃xff08;5&＃xff09;到此处,A在ready队列、B执行完、C在ready队列.

下一个时钟中断&＃xff0c;A优先调度直到执行完&＃xff0c;再执行完C。

&＃xff08;6&＃xff09;到此处&＃xff0c;所有线程执行完。但执行完的线程顺序&＃xff1a;B A C,并非预期的顺序(A B C)&＃xff0c;

因此A和B线程称为优先级反转&＃xff08;优先级低的线程B先于优先级高的A线程执行完&＃xff09;

3.优先级反转造成的后果

暂无实际案例&＃xff0c;但在实时嵌入式系统中会是灾难性的&＃xff0c;实时操作系统中&＃xff0c;每个任务的执行流时间片都是可控的&＃xff0c;譬如线程每次最大执行时间不能超过xx 毫秒.

每个业务线程的执行优先级是根据业务重要性逻辑来定义的&＃xff0c;假如优先级反转可能导致业务逻辑错乱.

现实举例&＃xff08;来自网络实例&＃xff09;&＃xff1a;

     当年火星探路者号&＃xff08;Mars Pathfinder&＃xff09;&＃xff0c;就由于优先级反转&＃xff0c;而导致了内部执行逻辑出错的bug&＃xff1a;

     在1997年7月4号发射后&＃xff0c;在开始搜集气象数据之后没几天&＃xff0c;系统&＃xff08;无故&＃xff09;重启了。

后来&＃xff0c;被相关技术人员找到问题根源&＃xff0c;就是&＃xff0c;这个优先级反转所导致的&＃xff0c;然后修复了此bug。

4.解决优先级反转方法

   在优先级反转第&＃xff08;3&＃xff09;中&＃xff0c;当现在A获取共享资源XXX时&＃xff0c;发现占用资源XXX的C线程优先级低于自己&＃xff0c;使用调度系统讲线程C的优先级临时上升到和自己线程A同等优先级.

   这样在下一个时钟中断调度时&＃xff0c;调度系统发现线程C优先级高于线程B&＃xff0c;就先运行线程C了。线程C运行释放完“通行证”&＃xff0c;A优先级最高先运行&＃xff0c;B居中,C最后。

最终线程完整执行完顺序为&＃xff1a;A  B  C