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
Loading
Please register or sign in to comment