-
如果某任务让出，调度算法可能会再次选择同一任务执行。如果某任务休眠， 则在指定的延迟时间到期前不可被选择。 同样，如果某任务阻塞， 则在特定事件发生（例如，数据到达 UART）或超时期满之前将不可被选择。
-
队列，互斥锁和信号量
2.1 队列
2.2 二进制信号量：（Note: 在许多情况下， “任务通知”可以提供计数信号量的轻量级替代方案）可以用size为1的队列来实现，只有空和满两种状态，一个任务只负责获取信号量，队列为空时，阻塞，队列为满时，获取成功，开始处理后续代码。另一个任务（或者中断）负责提供信号量，队列为满时？？？怎么办？另外，任务通知也可以作为信号量的实现，见后续
2.3 计数信号量：（Note: 在许多情况下， “任务通知”可以提供计数信号量的轻量级替代方案。）正如二进制信号量可以被认为是长度为 1 的队列那样， 计数信号量也可以被认为是长度大于 1 的队列。同样，信号量的使用者对存储在队列中的数据并不感兴趣， 他们只关心队列是否为空。根据不同用途，创建信号量时，一般可分为队列满和队列空两种状态。
2.4 互斥锁：互斥锁是包含优先级继承机制的二进制信号量 。鉴于二进制信号量是实现同步（任务之间或任务与中断之间） 的更好方式，因此互斥锁更适合实现简单的 相互排斥（即互斥）。优先级继承机制！
2.5 递归互斥锁：用户可对一把递归互斥锁重复加锁。只有用户 为每个成功的 xSemaphoreTakeRecursive() 请求调用 xSemaphoreGiveRecursive() 后，互斥锁才会重新变为可用。例如，如果一个任务成功“加锁”相同的互斥锁 5 次， 那么任何其他任务都无法使用此互斥锁，直到任务也把这个互斥锁“解锁”5 次。
- 任务通知
任务通知具有高度灵活性， 使得它们可以在 必须要创建单独队列、二进制信号量、计数信号量 或事件组的情况下进行使用。与通过诸如二进制信号量等中间对象来解除任务阻塞状态相比，通过直接通知解除 RTOS 任务阻塞状态的速度快 45%， 使用的 RAM 也更少。不过 这些性能优势也有一些意料之内的使用限制：
RTOS 任务通知仅可在只有一个任务 可以接收事件时使用。不过，这个条件在 大多数真实世界情况下是满足的。比如，中断解除了一个任务的阻塞状态，该任务 将处理由中断接收的数据。
仅可在使用 RTOS 任务通知代替 队列的情况下：当某个接收任务可在阻塞状态下等待通知 （因而不花费任何 CPU 时间）时，发送任务不能 在阻塞状态下等待发送完成（在发送不能立刻完成的情况下） 。
- 事件组和通知先不学。