tree 58e4e4174587c9a182c022111efb2c56a03aea95
parent 62948d8b502ea6e421ae1f188e34d05db8d973bd
author Steven Thomas <steventhomas@google.com> 1504229061 -0700
committer Steven Thomas <steventhomas@google.com> 1504730324 -0700

Fix race conditions when using mHwc off the main thread

In a few cases we were accessing mHwc off the main thread without
acquiring mStateLock, resulting in crashes and other incorrect
behavior. This CL adds the missing locks. Since the locking semantics
are somewhat hard to understand, also add a clarifying comment to the
mHwc member declaration in SurfaceFlinger.h.

Bug: 64586546

Test: I manually tested normal surface flinger operation and vr behavior
on different devices, and confirmed everything looks fine. The crashes
we saw that were caused by these mHwc race conditions are hard to
reproduce, so I couldn't empirically verify this fixes the crash. I'm
relying on manual code inspection to confirm the issue is in fact fixed.

Regarding performance, I added profiling code (not part of this CL) to
check for lock contention and hold times with the newly added locks. I
confirmed that contention is low, so these calls shouldn't be
significantly slower as a result of adding the locks. The time spent
holding these new locks is also low, except for getDisplayColorModes(),
which makes a call to hardware composer service and can in some cases
take over a millisecond. That function is called so rarely though, only
once at boot, or twice at boot after a fresh flash, that it's not worth
optimizing.

Change-Id: I3854779c12a61983aaaecddb9f6316f218e519e3