Randomize sync point starting number to reduce risk of GPU hangs.

content/common/gpu/sync_point_manager.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/common/gpu/sync_point_manager.h"
 
 #include "base/logging.h"
+#include "base/rand_util.h"
 
 namespace content {
 
+static const int kMaxSyncBase = 10000000;

[piman, 2014/05/14 19:21:29]

Because of the birthday paradox, the collision risk is 1/sqrt(kMaxSyncBase).
With this value it's not that low (.1%)... Any reason not to use, say 31 bits?
That still leaves at least half the range before wrapping (and even then,
wrapping is not necessarily bad, except we need to avoid 0).

+
 SyncPointManager::SyncPointManager()
-    : next_sync_point_(1) {
+    : next_sync_point_(base::RandInt(1, kMaxSyncBase)) {
+  // To reduce the risk that a sync point created in a previous GPU process
+  // will be in flight in the next GPU process, randomize the starting sync
+  // point number.

[piman, 2014/05/14 19:21:29]

nit: can you file a bug to revisit this (assign to me)? I'm hoping we can avoid
relying on randomness, maybe by enlarging sync points to 64 bits, and keeping
some of the bits for the GPU process host id.
Needs a lot of code changes everywhere, but it may be worth it at some point.

 }
 
 SyncPointManager::~SyncPointManager() {
 }
 
 uint32 SyncPointManager::GenerateSyncPoint() {
   base::AutoLock lock(lock_);
   uint32 sync_point = next_sync_point_++;
 
   // Note: wrapping would take days for a buggy/compromized renderer that would
@@ skipping 37 matching lines @@
 bool SyncPointManager::IsSyncPointRetired(uint32 sync_point) {
   DCHECK(thread_checker_.CalledOnValidThread());
   {
     base::AutoLock lock(lock_);
     SyncPointMap::iterator it = sync_point_map_.find(sync_point);
     return it == sync_point_map_.end();
   }
 }
 
 }  // namespace content