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

content/common/gpu/sync_point_manager.cc

Index: content/common/gpu/sync_point_manager.cc
diff --git a/content/common/gpu/sync_point_manager.cc b/content/common/gpu/sync_point_manager.cc
index 0e84e1cb99d41fb111f65c2a2bd50891291a1572..cdca472a5f742870d11d3631176dab1c79d6d9d1 100644
--- a/content/common/gpu/sync_point_manager.cc
+++ b/content/common/gpu/sync_point_manager.cc
@@ -5,11 +5,17 @@
 #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() {