Renderer reading side of gamepad

content/common/gamepad_hardware_buffer.h

Index: content/common/gamepad_hardware_buffer.h
diff --git a/content/common/gamepad_hardware_buffer.h b/content/common/gamepad_hardware_buffer.h
index d9845227710fcab6f09880320084a9d403d3f687..c673d06af9ece9a81826213f75ee92926f47eff8 100644
--- a/content/common/gamepad_hardware_buffer.h
+++ b/content/common/gamepad_hardware_buffer.h
@@ -5,10 +5,10 @@
 #ifndef CONTENT_COMMON_GAMEPAD_HARDWARE_BUFFER_H_
 #define CONTENT_COMMON_GAMEPAD_HARDWARE_BUFFER_H_
 
-#include "base/atomicops.h"
+#include "content/common/gamepad_seqlock.h"
 #include "third_party/WebKit/Source/WebKit/chromium/public/WebGamepads.h"
 
-namespace gamepad {
+namespace content {
 
 /*
 
@@ -19,25 +19,13 @@ we want low latency (so would like to avoid explicit communication via IPC
 between producer and consumer) and relatively large data size.
 
 Writer and reader operate on the same buffer assuming contention is low, and
-start_marker and end_marker are used to detect inconsistent reads.
-
-The writer atomically increments the start_marker counter before starting,
-then fills in the gamepad data, then increments end_marker to the same value
-as start_marker. The readers first reads end_marker, then the the data and
-then start_marker, and if the reader finds that the start and end markers were
-different, then it must retry as the buffer was updated while being read.
-
-There is a requirement for memory barriers between the accesses to the markers
-and the main data to ensure that both the reader and write see a consistent
-view of those values. In the current implementation, the writer uses an
-Barrier_AtomicIncrement for the counter, and the reader uses an Acquire_Load.
+contention is detected by using the associated SeqLock.
 
 */
 
 struct GamepadHardwareBuffer {
-  base::subtle::Atomic32 start_marker;
+  GamepadSeqLock sequence;
   WebKit::WebGamepads buffer;
-  base::subtle::Atomic32 end_marker;
 };
 
 }