The powerd main thread only ever checks fb_state with the mutex locked, and the monitor thread only ever changes it with the mutex locked. The main thread also only calls pthread_cond_wait() *after* finding fb_state != FB_AWAKE *without any intervening unlock of the mutex.* So the scenario you describe is impossible. If the monitor thread changes fb_state to FB_AWAKE before the main thread locks the mutex, it will see fb_state == FB_AWAKE on the first loop iteration and never call pthread_cond_wait(). If the main thread locks the mutex before the monitor thread changes the state then the monitor thread cannot change the state until pthread_cond_wait() releases the mutex, then the subsequent pthread_cond_signal() call will awaken the main thread.
The powerd main thread only ever checks fb_state with the mutex locked, and the monitor thread only ever changes it with the mutex locked. The main thread also only calls pthread_cond_wait() *after* finding fb_state != FB_AWAKE *without any intervening unlock of the mutex.* So the scenario you describe is impossible. If the monitor thread changes fb_state to FB_AWAKE before the main thread locks the mutex, it will see fb_state == FB_AWAKE on the first loop iteration and never call pthread_ cond_wait( ). If the main thread locks the mutex before the monitor thread changes the state then the monitor thread cannot change the state until pthread_cond_wait() releases the mutex, then the subsequent pthread_ cond_signal( ) call will awaken the main thread.