- 在 POSIX 和 Win32 中, boost::condition 是使用基于事件的 API 实现的。从技术上讲,线程在收到事件之前不会唤醒。
- 如果在发送信号后线程进入等待状态 - 信号将丢失。您应该阅读有关实现“生产者/消费者”的基于事件的模式和策略。您的文件写入/读取示例是经典的生产者/消费者实例。为了避免丢失信号,请类似于 Wikipedia 中的 C++11 示例来实现它:http ://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem#Example_in_C.2B.2B
这个想法是如果 thread1 不等待条件,它将始终锁定共享互斥锁:
//thread1 - consumer
void thread1() {
boost::scoped_lock lock(sharedMutex);
// shared mutex locked, no events can be sent now
while(1) {
// check for files written by thread2
sharedCond.wait( lock ); // this action unlocks the shared mutex, events can be sent now
}
}
//thread2 - producer
void thread2() {
boost::scoped_lock lock(sharedMutex); // will wait here until thread 1 starts waiting
// write files
sharedCond.notify_one();
}
3.性能问题:这个变化不是关于性能,而是将轮询改为事件模型。如果您的线程 1 每 1 秒唤醒一次,则切换到事件模型不会改善 CPU 或 I/O 负载(消除每 1 秒一次的文件验证),直到您在频率为几 KHz 且 I/O 操作阻塞的嵌入式系统中运行整个过程。它将提高线程 1 的反应时间,在轮询模式下,文件更改的最大响应时间为 1 秒,切换到事件后将立即采取行动。另一方面,线程 2 的性能可能会在事件模型中下降——在它没有等待任何东西之前,如果它使用条件——它必须锁定共享互斥体,这可能在线程 1 读取文件时一直被锁定。