



已经被封装为一条机器指令,也就意味着,在执行这条指令的时候不会被打断。不允许出现中断和切换的,只有完成整个语句之后,才会进行下一步,比如产生中断/切换


忙等,消耗的CPU资源比较多,有什么办法不让他忙等呢,
办法:
前面讲过,大家都知道当一个进程它等待某个事件的时候,它可以去睡眠,其实可以把这个概念引入到这个进入临界区里面来也是一样的,如果我们发现这个进程它现在正在等待且进不到临界区,可以让这个进程去阻塞睡眠,意味着进程进入等待队列里面去,然后就可以把这个CPU让出来给其它进程执行,
一旦进入临界区的进程退出临界区的时候,它会去把这个value赋成0,同时还完成一个操作,就是唤醒操作,这和我们之前讲的进程管理是一样的,通过唤醒操作使得等待进入临界区的进程重新去判断是否可以完成这个 test-and-set,可以跳出这个循环,一旦跳出,它也可以进入临界区,如果跳不出去,不得不再次进入睡眠,这就是不用去忙等待的实现方式。
这种方式和忙等方式相比,对于如果临界区执行事件很短的情况下,更加愿意选择忙等的方式,因为不需要跟刚才那种方式一样完成上下文切换,上下文切换相对来说也是一个开销比较大的操作,如果说这个临界区很长,开销远远大于这个上下文切换的开销,那么我们更愿意选择这种基于上下文切换非忙等的方式。
如何用exchange指令来实现锁呢?


缺点:
死锁:
·如果一个低优先级的进程拥有临界区并且一个高优先级进程也需求,那么高优先级进程会获得处理器并等待临界区(可以用之前说的优先级反转来解决)
解释:低优先级的进程还没来得级释放锁,就被高优先级的进程抢占CPU,而高优先级的进程刚好也要访问那个临界区,高优先级进程就陷入了 忙等待状态

文章讨论了在处理临界区时避免忙等的方法,即当进程无法进入临界区时,让它睡眠以释放CPU资源。通过使用阻塞和唤醒操作,可以实现非忙等待的策略。尽管上下文切换有开销,但在临界区执行时间较长时,这种方式更为可取。此外,文章提到了使用exchange指令实现锁以及死锁问题,特别是优先级反转导致的高优先级进程忙等待的情况。

被折叠的 条评论
为什么被折叠?



