surfaceflinger: use Mutex timedLock instead of tryLock loop
Rather than trying to acquire the state lock without waiting three times at 1 second intervals in SurfaceFlinger::dump(), just try to acquire the lock once with a 1 second timeout. Avoids spurious mutex acquire failures that lead to flaky com.android.cts.jank.opengl.CtsHostJankOpenGl results. Bug: 18842510 Change-Id: I00ce6109647de2aef8831dd2f8fa98652ba7f4e0
This commit is contained in:
parent
033f7e8e35
commit
fcd15b478c
@ -2359,18 +2359,15 @@ status_t SurfaceFlinger::dump(int fd, const Vector<String16>& args)
|
||||
result.appendFormat("Permission Denial: "
|
||||
"can't dump SurfaceFlinger from pid=%d, uid=%d\n", pid, uid);
|
||||
} else {
|
||||
// Try to get the main lock, but don't insist if we can't
|
||||
// Try to get the main lock, but give up after one second
|
||||
// (this would indicate SF is stuck, but we want to be able to
|
||||
// print something in dumpsys).
|
||||
int retry = 3;
|
||||
while (mStateLock.tryLock()<0 && --retry>=0) {
|
||||
usleep(1000000);
|
||||
}
|
||||
const bool locked(retry >= 0);
|
||||
status_t err = mStateLock.timedLock(s2ns(1));
|
||||
bool locked = (err == NO_ERROR);
|
||||
if (!locked) {
|
||||
result.append(
|
||||
"SurfaceFlinger appears to be unresponsive, "
|
||||
"dumping anyways (no locks held)\n");
|
||||
result.appendFormat(
|
||||
"SurfaceFlinger appears to be unresponsive (%s [%d]), "
|
||||
"dumping anyways (no locks held)\n", strerror(-err), err);
|
||||
}
|
||||
|
||||
bool dumpAll = true;
|
||||
|
Loading…
Reference in New Issue
Block a user