Implement the content/renderer and content/browser part of the Device Motion API.

content/common/shared_memory_seqlock_buffer.h

+// Copyright (c) 2013 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_SHARED_MEMORY_SEQLOCK_BUFFER_H_
+#define CONTENT_COMMON_SHARED_MEMORY_SEQLOCK_BUFFER_H_
+
+#include "content/common/gamepad_seqlock.h"
+
+namespace content {
+
+// This structure is stored in shared memory that's shared between the browser
+// which does the hardware polling, and the consumers of the device motion
+// data, i.e. the renderers. The performance characteristics are that
+// 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
+// contention is detected by using the associated SeqLock.
+
+template<class Data>
+struct SharedMemorySeqLockBuffer {
+  GamepadSeqLock sequence;

[darin (slow to review), 2013/06/17 20:23:44]

nit: seems like GamepadSeqLock needs to be renamed, right?

[timvolodine, 2013/06/18 16:44:31]

Done.

renamed to OneWriterSeqLock.

+  Data buffer;

[darin (slow to review), 2013/06/17 20:23:44]

nit: maybe "buffer" should be named "data" to match the name of the data type? 
plus, that way you can say that the buffer's data is given by the "data" member
variable.  otherwise, you have the buffer's data is given by the "buffer" member
variable, and you end up with code like "buffer->buffer" which tends to be a bit
awkward.

[timvolodine, 2013/06/18 16:44:31]

absolutely agree, Done.

+  bool is_ready_for_read;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_COMMON_SHARED_MEMORY_SEQLOCK_BUFFER_H_