Prevent race condition

Question

I wrote a timer which works in the following way: a class using the timer implements a callback function call_(). The timer runs in a separate thread and executes call_() when the timer expires.

My test program is as follows:

void TestCase::loop()
{
  unique_lock<mutex> lock(*this);

  while(running_)
  {
     timer_->SetTimer(time);
     signal_.wait(lock);
     do_something();
  }
}

void TestCase::call_()
{
  signal_.notify_all();
}

If time is very small (e.g. 2ms) the test program sometimes executes do_something() , sometimes not (in different runs of the test program).

My guess is a race condition, it seems that if time is small call()_ is executed (and thus signal_.notify_all() ) before signal_.wait(lock).

If I add this_thread::sleep(posix_time::milliseconds(2)) before signal_.notify_all(), do_something() is executed in almost every run and for sleep(5) everything works fine.

How can I assure that signal_.wait(lock) is executed before signal_.notify_all()?

Where are you changing the value of running_? My guess is that your problem has more to do with that variable. — Jorge González Lorenzo, Nov 29 '12 at 10:14
If you have to ensure 'wait' executes before 'notify', it's the wrong type of signal. You need a thread-safe condition variable in there. — ActiveTrayPrntrTagDataStrDrvr, Nov 29 '12 at 10:18
in the test programm running_ is set to true in the constructor and set to false in the destructor of TestCase — Michael, Nov 29 '12 at 10:19
@ActiveTrayPrntrTagDataStrDrvr: this was my first thought :-) I used `boost::conditional_variable signal_` Does boost have thread-safe condition variables? I did not find something in the doc. — Michael, Nov 29 '12 at 11:48
Try looking at this: http://stackoverflow.com/questions/1677070/cross-platform-equivalent-to-windows-events — ActiveTrayPrntrTagDataStrDrvr, Nov 29 '12 at 12:01
Is your timer an interval timer (invokes `call_` repeatedly every X ms) or a one-shot timer (invokes `call_` exactly once, X ms after starting the timer)? — Bart van Ingen Schenau, Nov 29 '12 at 13:01

score 1 · Accepted Answer · answered Nov 29 '12 at 13:52

With very small timeout values, there is no way to guarantee that the main thread reaches the signal_wait statement before the timer thread executes the signal_.notify_all statement.

As you are using a one-shot timer, a better alternative would be to use a semaphore instead of a condition variable to synchronize the two threads.

As you saw with condition variables, there is an order in which the wait and notify must be executed in order for the mechanism to work correctly.

With a semaphore, the thread executing the wait will also be stopped until another thread posts the semaphore, but there is no requirement in which order the wait and post operations are reached. If the post was reached first, the wait just returns immediately (and successful).

Thanks, that solved my problem. I hestitaded implementing a semaphore class myself because I wasn't sure if boost offers a simpler solution (as there are no semaphores in boost) — Michael, Nov 30 '12 at 10:23
There are semaphores in the Boost.Interprocess library. And you could use a `Barrier` instead of a semaphore (that just keeps both threads waiting on each other, instead of only thread A until thread B has passed a certain point) — Bart van Ingen Schenau, Nov 30 '12 at 10:36

Prevent race condition

1 Answers1