Renderer reading side of gamepad

content/common/gamepad_seqlock.h

+// Copyright (c) 2011 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.
+
+#ifndef CONTENT_COMMON_GAMEPAD_SEQLOCK_H_
+#define CONTENT_COMMON_GAMEPAD_SEQLOCK_H_
+
+#include "base/atomicops.h"
+#include "base/threading/platform_thread.h"
+
+namespace gamepad {

[darin (slow to review), 2011/11/30 18:34:37]

I think we probably want new code in the content/ module to be in the content::
namespace.  Jam confirms.

[scottmg, 2011/11/30 19:43:31]

Phew, that turned out to be a lot of places (not content::gamepad::, just
content::, right?).

Couple classes deserved to be renamed when living in content:: (Provider ->
GamepadProvider, DataFetcher -> GamepadDataFetcher) so there's some (more)
noise. Seems tidier overall though.

+
+// This SeqLock handles only *one* writer and multiple readers. It may be
+// suitable for low-contention with relatively infrequent writes, and many
+// readers. See:
+//   http://en.wikipedia.org/wiki/Seqlock
+//   http://www.concurrencykit.org/doc/ck_sequence.html
+// This implementation is based on ck_sequence.h from http://concurrencykit.org.
+//
+// Currently, this is used in only one location. It may make sense to
+// generalize with a higher-level construct that owns both the lock and the
+// data buffer, if it is to be used more widely.
+//
+// You must be very careful not to operate on potentially inconsistent read
+// buffers. If the read must be retry'd, the data in the read buffer could
+// contain any random garbage. e.g., contained pointers might be
+// garbage, or indices could be out of range. Probably the only suitable thing
+// to do during the read loop is to make a copy of the data, and operate on it
+// only after the read was found to be consistent.
+class GamepadSeqLock {
+ public:
+  GamepadSeqLock() : sequence_(0) {}
+
+  base::subtle::Atomic32 ReadBegin() {

[darin (slow to review), 2011/11/30 18:34:37]

why inline these functions?

[scottmg, 2011/11/30 19:43:31]

4/5 seemed trivial enough (other than ReadBegin), but there's not a major
benefit either i guess: moved out of line.

+    base::subtle::Atomic32 version;
+    for (;;) {
+      version = base::subtle::NoBarrier_Load(&sequence_);
+
+      // If the counter is even, then the associated data might be in a
+      // consistent state, so we can try to read.
+      if ((version & 1) == 0)
+        break;
+
+      // Otherwise, the writer is in the middle of an update. Retry the read.
+      base::PlatformThread::YieldCurrentThread();
+    }
+    return version;
+  }
+
+  bool ReadRetry(base::subtle::Atomic32 version) {
+    // If the sequence number was updated then a read should be re-attempted.
+    // -- Load fence, read membarrier
+    bool ret = base::subtle::Release_Load(&sequence_) != version;
+    return ret;
+  }
+
+  void WriteBegin() {
+    // Increment the sequence number to odd to indicate the beginning of a
+    // write update.
+    base::subtle::Barrier_AtomicIncrement(&sequence_, 1);
+    // -- Store fence, write membarrier
+  }
+
+  void WriteEnd() {
+    // Increment the sequence to an even number to indicate the completion of
+    // a write update.
+    // -- Store fence, write membarrier
+    base::subtle::Barrier_AtomicIncrement(&sequence_, 1);
+  }
+
+ private:
+  base::subtle::Atomic32 sequence_;
+  DISALLOW_COPY_AND_ASSIGN(GamepadSeqLock);
+};
+
+}  // namespace gamepad
+
+#endif  // CONTENT_COMMON_GAMEPAD_SEQLOCK_H_