What is the best way to make a parent thread wait after initializing a child pthread until it receives some signal from the child?

Immediately after spawning a thread with pthread_create, I would like the parent to wait an arbitrary amount of time until the child thread allows it to continue. Here is how I might approach it with a mutex:

pthread_mutex_t childLock;

void *childProcess()
{
    pthread_mutex_lock(&childLock);
    // do important initialization
    pthread_mutex_unlock(&childLock);
    // do some parallel processing
}

int main()
{
    pthread_t childThread;
    pthread_create(&childThread, 0, childProcess);
    pthread_mutex_lock(&childLock); // wait here for child initialization
    // do some parallel processing
    pthread_join(childThread, 0);
    return 0;
}

The issue here is that there's no guarantee childProcess will get the mutex first, so the behavior is undefined. I can come up with a few ways to resolve this, but I'm not happy with any of them:

1. Sleep in the main thread before acquiring the mutex. I don't think this is technically a guarantee that the child will win the race, and I'd like to avoid sleeping in either thread if I can.
2. Ditch mutexes and wait in a while loop for the child to update a signal variable. I wouldn't want to waste precious cycles busy waiting if I don't have to.
3. Transfer mutex ownership from parent to child? I'm not sure if this is possible and it seems a bit evil, but it would solve the problem without sleeping or busy waiting. The idea is to lock the mutex in main, then transfer the lock into the child when spawning the thread so it is guaranteed to have the lock first.

What other options are there? The solution only needs to work with Linux and GCC.

1. Sleep in the main thread before acquiring the mutex. I don't think this is technically a guarantee that the child will win the race, and I'd like to avoid sleeping in either thread if I can.

On one hand, this indeed does not guarantee that the new thread wins the race, and on the other hand, it does make it likely that the main thread will be delayed much longer than it needs to be. sleep() is not a synchronization or IPC device.

2. Ditch mutexes and wait in a while loop for the child to update a signal variable. I wouldn't want to waste precious cycles busy waiting if I don't have to.

This is actually viable, provided that you use an atomic signal variable. C has those built-in since C99, but I'm uncertain whether C++03 has them.

3. Transfer mutex ownership from parent to child? I'm not sure if this is possible

It's not possible.

What other options are there? The solution only needs to work with Linux and GCC.

Simplest would probably be to use a semaphore. The main thread initializes it with value 0. After starting the other thread, the main thread attempts to decrement the semaphore, which blocks until the child increments it (if it hasn't done so already).

That requires setting up only one synchronization object rather than two (mutex + cv), and the usage idiom is simpler than that of mutex + cv.

Also, this is adaptible without change to starting multiple threads (as mutex + cv also could be), for after the initial thread regains control, the semaphore is already prepared for another cycle.

Example code:

sem_t thread_start_lock;

void *thread(void *arg) {
    // do something ...

    sem_post(&thread_start_lock);  // probably abort() if this fails

    // ...
}

int main(void) {
   sem_init(&thread_start_lock, 0, 0);  // probably terminate if this fails

   pthread_t thread_id;
   pthread_create(&thread_id, NULL, thread, NULL);
   sem_wait(&thread_start_lock);

   // ...
}

Of course, for robustness you need to check return codes and handle errors. The code contains a couple of notes about that, but all the function calls presented need to be checked, not just the annotated ones.