- In POSIX and Win32 boost::condition is implemented using event based APIs. Technically thread doesn't wake up until it gets an event.
- If thread goes into wait after the signal has been sent - the signal would be lost. You should read about event based patterns and strategies for implementing "producer/consumer". Your file write/read example is classic producer/consumer instance. In order to avoid lost signal please implement it similar to the C++11 example in Wikipedia: http://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem#Example_in_C.2B.2B
The idea is that thread1 will always lock shared mutex if it doesn't wait for condition:
//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. Performance question: this change is not about the performance, but changing the polling to event model. If your thread1 was awake every 1 second, switching to event model won't improve CPU or I/O load (eliminate file verification every 1 second), until you run in embedded system where frequency is few KHz and I/O operation blocks the entire process. It will improve thread1 reaction time, in polling mode the max response time to file change would be 1 second, and after switching to event it would be immediate action. On the other hand thread2 performance might degrade in event model - before it didn't wait for anything, and if it uses condition - it will have to lock the shared mutex, that might be locked all time thread1 is reading the files.