内部实现信号量semPOSIX sem_t信号量的用处需要计数任务时因为信号量可以统计数量当中任务通知用实际上FreeRTOS的任务通知就是轻量化的二进制信号量可以替代掉二进制信号量当互斥锁用但是不推荐因为无法解决优先级反转的问题事件evtpthread_cond_tpthread_mutex_t主要依靠条件变量实现使用区别信号量需要计数事件只有两种状态不需要信号量计数的情况下区别1先Post释放后Pend请求结果不同信号量sem_postPost 会累加计数即使没人等也不丢计数0→1 → 计数1→0立即返回成功 ✓OS_SemPost 底层是 sem_post它会把信号量的值从0加到1这个值会保留下来后续 sem_wait 来了直接拿走不会阻塞。事件pthread_cond_signalPost 时没人在等signal 就丢了无人等待signal丢失 → 永远阻塞 ✗OS_EvtPost 底层是 pthread_cond_signal它只是唤醒当前正在 pthread_cond_wait 上的线程。如果那一刻没有线程在 wait这个 signal 就消失了什么也没留下。区别2事件存在虚假唤醒pthread_cond_wait 在 Linux 上可能没有人 Post 也会自己醒来操作系统实现层面的已知问题所以条件变量的正确用法必须配合 while 循环和条件变量检查条件变量pthread_cond的不可替代之处在上面的描述过程当中好像感觉pthread_cond挺没有用的实则不然。广播唤醒信号量的 sem_post 每次只能让一个 sem_wait 返回。如果想唤醒5个线程必须 sem_post 5次。条件变量的 pthread_cond_broadcast 可以一次唤醒所有正在等待的线程。等的是条件不是信号信号量只能告诉你有人 Post 了但不知道具体是什么条件满足了。条件变量的真正用法是等待某个条件为真而不是等待一个信号。信号量思维等一个通知 → 通知来了就往下走条件变量思维等一个条件 → 条件满足才往下走不满足继续等信号丢失的优势条件变量3次上报 → 只保留最新1次通知 → 处理线程醒来1次只处理最新数据
