gap between an unlock and a lock..

Hi, I've got a small question:

Code:

Telepathic::Message TelepatiaChannel::getMessage(){
   hasIncoming.waitUntilTrue(); // point 1
   incoming_lock.Lock(); // point 2
   assert(incoming.size() > 0); // point 3
   Telepathic::Message msg = incoming.front();
   incoming.pop_front();
   incoming_lock.Unlock();

   return msg;

}

What the code does is pretty simple, it waits for the WaitableBool "hasIncoming" to be true, then it locks incoming_lock..

The WaitableBool class is from another thread I started months ago : waitable boolean class (concurrency)

Now the question is, suppose I have two or more threads calling this function, all waiting at point 1. As soon as hasIncoming switches to true, one of the threads will move to point two. Is there a chance that, a thread (say, thread A) will take control inside point 1, and then lose control before it reaches point 2?

Because this could cause a situation where a thread thinks that there's available data, and comes and finds that there's no data, therefore triggering point 3..

I'm thinking that I have to actually change the code above, to make the thread wait again if it finds that there's no data.

So yeah, anybody know if my suspicion is right?

Thanks in advance

This is what I changed it to.. am I overkilling it?

Code:

   while(true){
      hasIncoming.waitUntilTrue();
      incoming_lock.Lock();
      if(incoming.size() > 0){
         Telepathic::Message msg = incoming.front();
         incoming.pop_front();
         incoming_lock.Unlock();
         return msg;
      } else {
         incoming_lock.Unlock();
      }
      
   }

I'm not sure what OS you are using but Windows has solved this problem via critical sections. If two threads enter at the same time one is allowed to 'win' and the other then holds at an implicit WaitForSingleObject. When the thread that 'won' leaves the critical section, the thread that is waiting then proceeds into the critical section and takes ownership of it.

There is more information on MSDN about critical sections.

In general, yes it possible that a thread may gain control at point 1 but lose it just prior to point 2 or somewhere iniside point 2 and another thread would take control at point 2 and lock.
Until you lock via a mutex or use a critical section, it's a race.

Cool, understood, thanks!

What you need is a condition variable. That's basically your waitable bool, but it atomically locks a mutex before waking the thread, and if the mutex cannot be locked, it keeps waiting.

POSIX threads natively has condition variables. Windows Vista also offers them. Under XP, you have to emulate them. Boost.Threads offers a condition variable that works cross-platform.

POSIX threads natively has condition variables. Windows Vista also offers them. Under XP, you have to emulate them. Boost.Threads offers a condition variable that works cross-platform.

I've tried using condition variables inside of XP with little success. It has been my experience that unless a kernel level object is used it won't work. How would you go about creating a condition variable in a Win32 program? I've tried using bools to 'gate' thread entries to functions and blocks of code with absolutely no success.

I wouldn't. I'd just use Boost's condition variable.

The implementation of that is here:
http://svn.boost.org/trac/boost/brow...n_variable.hpp