Comment 1 for bug 1450017

OK, here's a wild theory. Looking at powerd/libsuspend/earlysuspend.c and reading the 0.5s kernel delay comments in bug 1421455...

Why don't earlysuspend_exit and _enter lock the mutex before making the sysfs_write call? Seems like they could miss the pthread_cond_signal call depending on thread timing.

Consider:
- Main powerd thread writes to /sys/power/state
- Kernel does it's thing, maybe takes a while, updates /sys/power/state
- Listening powerd thread notices FB_AWAKE state, locks mutex, emits cond_signal, and then blocks waiting for FB_SLEEP state
- Main powerd thread enters the mutex locking section, locks mutex, waits for FB_AWAKE signal (that it missed)

Now powerd is blocked forever until someone else writes to /sys/power/state, right?

If powerd simply locked the mutex before writing to /sys/power/state, the listening thread would be forced to wait to update fb_state until the main thread gave up the lock via pthread_cond_wait and no one would miss any cond_signals.

(Threading is not my forte, so I'm probably missing something.)