如何避免线程+优化器==无限循环？

Question

In a code review today, I stumbled across the following bit of code (slightly modified for posting):

while (!initialized)
{
  // The thread can start before the constructor has finished initializing the object.
  // Can lead to strange behavior. 
  continue;
}

This is the first few lines of code that runs in a new thread. In another thread, once initialization is complete, it sets initialized to true .

I know that the optimizer could turn this into an infinite loop, but what's the best way to avoid that?

• volatile - considered harmful
• calling an isInitialized() function instead of using the variable directly - would this guarantee a memory barrier? What if the function was declared inline ?

Are there other options?

Edit:

Should have mentioned this sooner, but this is portable code that needs to run on Windows, Linux, Solaris, etc. We use mostly use Boost.Thread for our portable threading library.

Answer 1

Calling a function won't help at all; even if a function is not declared inline , its body can still be inlined (barring something extreme, like putting your isInitialized() function in another library and dynamically linking against it).

Two options that come to mind:

• Declare initialized as an atomic flag (in C++0x, you can use std::atomic_flag ; otherwise, you'll want to consult the documentation for your threading library for how to do this)

• Use a semaphore; acquire it in the other thread and wait for it in this thread.

Answer 2

@Karl's comment is the answer. Don't start processing in thread A until thread B has finished initialization. They key to doing this is sending a signal from thread B to thread A that it is up & running.

You mentioned no OS, so I will give you some Windows-ish psudocode. Transcode to the OS/library of your choice.

First create a Windows Event object. This will be used as the signal:

Thread A:

HANDLE running = CreateEvent(0, TRUE, FALSE, 0);

Then have Thread A start Thread B, passing the event along to it:

Thread A:

DWORD thread_b_id = 0;
HANDLE thread_b = CreateThread(0, 0, ThreadBMain, (void*)handle, 0, &thread_b_id);

Now in Thread A, wait until the event is signaled:

Thread A:

DWORD rc = WaitForSingleObject(running, INFINITE);
if( rc == WAIT_OBJECT_0 )
{
  // thread B is up & running now...
  // MAGIC HAPPENS
}

Thread B's startup routine does its initialization, and then signals the event:

Thread B:

DWORD WINAPI ThreadBMain(void* param)
{
  HANDLE running = (HANDLE)param;
  do_expensive_initialization();
  SetEvent(running); // this will tell Thread A that we're good to go
}

Answer 3

Synchronization primitives are the solution to this problem, not spinning in a loop... But if you must spin in a loop and can't use a semaphore, event, etc, you can safely use volatile . It's considered harmful because it hurts the optimizer. In this case that's exactly what you want to do, no?

Answer 4

There is a boost equivalent of atomic_flag which is called once_flag in boost::once. It may well be what you want here.

Effectively if you want something to be constructed the first time it is called, eg lazy loading, and happens in multiple threads, you get boost::once to call your function the first time it is reached. The post-condition is that it has been initialized so there is no need for any kind of looping or locking.

What you do need to ensure is that your initialization logic does not throw exceptions.

Answer 5

This is a well known problem when working with threads. Creation/Initialization of objects takes relatively little time. When the thread actually starts running though... That can take quite a long time in terms of executed code.

Everyone keeps mentioning semaphores...

You may want to look at POSIX 1003.1b semaphores. Under Linux, try man sem_init . Eg:

• http://manpages.ubuntu.com/manpages/dapper/man3/sem_init.3.html
• http://www.skrenta.com/rt/man/sem_init.3.html
• http://docs.oracle.com/cd/E23824_01/html/821-1465/sem-init-3c.html

These semaphores have the advantage that, once Created/Initialized, one thread can block indefinitely until signaled by another thread. More critically, that signal can occur BEFORE the waiting thread starts waiting. (A significant difference between Semaphores and Condition Variables .) Also, they can handle the situation where you receive multiple signals before waking up.