本帖最后由 霸王猫 于 2020-2-26 10:28 编辑
1、是不是堵塞时,这个任务就一直等待
你的理解是片面的,不准确。
当程序中调用操作系统的堵塞API函数时,操作系统将当前任务的ID放入到【等待的信号量的等待列表里面】。然后做一次任务切换,跳转到处于就绪状态的最高优先级的任务中继续运行。
刚刚被堵塞的任务再也不会被执行,不存在【这一段代码处于等待中】这种说法,因为CPU连被堵塞的任务都不予理睬,哪还有【这一段代码处于等待中】这种说法呀!
被堵塞的任务再也无法获得CPU的控制权啦!除非解除堵塞,也就不存在【这一段代码处于等待中】这种说法。
注:如果堵塞任务是等待消息队列,则收到消息队列则解锁;
如果堵塞任务是等待信号量,则收到信号量则解锁;
如果堵塞任务是等待互斥信号量,则收到互斥信号量则解锁;
被堵塞的任务解锁后,操作系统将其从【等待的信号量的等待列表里面】删除,让其添加到就绪等待列表中,让其处于就绪状态,可以被操作系统调度。
可以被操作系统调度就是说,这个任务可以获得CPU的控制权了。注:可以获得CPU的控制权并不代表你能够立即获得CPU,原因参见下面:
(1)、如果【堵塞的任务又处于就绪状态】时,它的优先级最高,则该被堵塞的任务【立即】获得CPU的控制权,则CPU继续从阻塞前的断点处继续执行代码。
(2)、如果【堵塞的任务又处于就绪状态】时,它的优先级不是最高,则该被堵塞的任务【还不能立即】获得CPU的控制权,它要等到比它优先级高的任务依次获得CPU的控制权,然后处于阻塞状态时,【堵塞的任务又处于就绪状态】的任务获得CPU的控制权,则CPU继续从阻塞前的断点处继续执行代码。
|