Question

In a multi threaded app, is

while (result->Status == Result::InProgress) Sleep(50);
//process results

better than

while (result->Status == Result::InProgress);
//process results

?
By that, I’m asking will the first method be polite to other threads while waiting for results rather than spinning constantly? The operation I’m waiting for usually takes about 1-2 seconds and is on a different thread.

Answer 1

It’s better, but not by much.

As long as result->Status is not volatile, the compiler is allowed to reduce

while(result->Status == Result::InProgress);

to

if(result->Status == Result::InProgress) for(;;) ;

as the condition does not change inside the loop.

Calling the external (and hence implicitly volatile) function Sleep changes this, because this may modify the result structure, unless the compiler is aware that Sleep never modifies data. Thus, depending on the compiler, the second implementation is a lot less likely to go into an endless loop.

There is also no guarantee that accesses to result->Status will be atomic. For specific memory layouts and processor architectures, reading and writing this variable may consist of multiple steps, which means that the scheduler may decide to step in in the middle.

As all you are communicating at this point is a simple yes/no, and the receiving thread should also wait on a negative reply, the best way is to use the appropriate thread synchronisation primitive provided by your OS that achieves this effect. This has the advantage that your thread is woken up immediately when the condition changes, and that it uses no CPU in the meantime as the OS is aware what your thread is waiting for.

On Windows, use CreateEvent and co. to communicate using an event object; on Unix, use a pthread_cond_t object.