Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(777)

Unified Diff: content/common/one_writer_seqlock.h

Issue 14678012: Implement the content/renderer and content/browser part of the Device Motion API. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: factored out as much code as possible from the templated reader Created 7 years, 6 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
Index: content/common/one_writer_seqlock.h
diff --git a/content/common/one_writer_seqlock.h b/content/common/one_writer_seqlock.h
new file mode 100644
index 0000000000000000000000000000000000000000..6774df6c0156a467041dd8c29445bcc85777cea5
--- /dev/null
+++ b/content/common/one_writer_seqlock.h
@@ -0,0 +1,46 @@
+// 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_ONE_WRITER_SEQLOCK_H_
+#define CONTENT_COMMON_ONE_WRITER_SEQLOCK_H_
+
+#include "base/atomicops.h"
+#include "base/threading/platform_thread.h"
+#include "content/common/content_export.h"
+
+namespace content {
+
+// 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 type of lock is used in two implementations (gamepad and
+// device motion, in particular see e.g. shared_memory_seqlock_buffer.h).
+// It may make sense to generalize this lock to multiple writers.
+//
+// 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 CONTENT_EXPORT OneWriterSeqLock {
darin (slow to review) 2013/06/24 23:40:34 nit: Since you didn't freshly write these files, c
timvolodine 2013/06/25 03:36:07 Done.
+ public:
+ OneWriterSeqLock();
+ base::subtle::Atomic32 ReadBegin();
+ bool ReadRetry(base::subtle::Atomic32 version);
+ void WriteBegin();
+ void WriteEnd();
+
+ private:
+ base::subtle::Atomic32 sequence_;
+ DISALLOW_COPY_AND_ASSIGN(OneWriterSeqLock);
+};
+
+} // namespace content
+
+#endif // CONTENT_COMMON_ONE_WRITER_SEQLOCK_H_

Powered by Google App Engine
This is Rietveld 408576698