summaryrefslogtreecommitdiff
path: root/opengl/tests/gl_basic/gl_basic.cpp
diff options
context:
space:
mode:
authorSteven Thomas <steventhomas@google.com>2017-08-31 18:24:21 -0700
committerSteven Thomas <steventhomas@google.com>2017-09-06 13:38:44 -0700
commit6d8110b1708171da278782d18886fa1a21971cd9 (patch)
tree58e4e4174587c9a182c022111efb2c56a03aea95 /opengl/tests/gl_basic/gl_basic.cpp
parent62948d8b502ea6e421ae1f188e34d05db8d973bd (diff)
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
Diffstat (limited to 'opengl/tests/gl_basic/gl_basic.cpp')
0 files changed, 0 insertions, 0 deletions