summaryrefslogtreecommitdiff
path: root/src/third_party/wiredtiger/src/include/gcc.h
diff options
context:
space:
mode:
authorAlexander Gorrod <alexander.gorrod@mongodb.com>2015-06-26 05:32:26 +0000
committerAlexander Gorrod <alexander.gorrod@mongodb.com>2015-06-26 05:32:26 +0000
commit2f1b8b9a8a4754d08b730cc377f4b6a299f3ff43 (patch)
tree6b60321ab416de76877c47651aec988be592daba /src/third_party/wiredtiger/src/include/gcc.h
parent8152573ed2eae299001b2e4d459c3caf4f8fe245 (diff)
downloadmongo-2f1b8b9a8a4754d08b730cc377f4b6a299f3ff43.tar.gz
Import wiredtiger-wiredtiger-2.6.1-132-gfbaf1cf.tar.gz from wiredtiger branch mongodb-3.2
Diffstat (limited to 'src/third_party/wiredtiger/src/include/gcc.h')
-rw-r--r--src/third_party/wiredtiger/src/include/gcc.h15
1 files changed, 12 insertions, 3 deletions
diff --git a/src/third_party/wiredtiger/src/include/gcc.h b/src/third_party/wiredtiger/src/include/gcc.h
index cb9d3d5e212..889fd908388 100644
--- a/src/third_party/wiredtiger/src/include/gcc.h
+++ b/src/third_party/wiredtiger/src/include/gcc.h
@@ -33,7 +33,7 @@
* For example, if 8-bits of a 32-bit quantity were written, then the rest of
* the 32-bits were written, and another thread of control was able to read the
* memory location after the first 8-bits were written and before the subsequent
- * 24-bits were written, WiredTiger would break. Or, if two threads of control
+ * 24-bits were written, WiredTiger would break. Or, if two threads of control
* attempt to write the same location simultaneously, the result must be one or
* the other of the two values, not some combination of both.
*
@@ -44,7 +44,7 @@
* adjacent 32-bit locations. The problem is when two threads are cooperating
* (thread X finds 32-bits set to 0, writes in a new value, flushes memory;
* thread Y reads 32-bits that are non-zero, does some operation, resets the
- * memory location to 0 and flushes). If thread X were to read the 32 bits
+ * memory location to 0 and flushes). If thread X were to read the 32 bits
* adjacent to a different 32 bits, and write them both, the two threads could
* race. If that can happen, you must increase the size of the memory type to
* a type guaranteed to be written atomically in a single cycle, without writing
@@ -139,10 +139,10 @@
/* Compile read-write barrier */
#define WT_BARRIER() __asm__ volatile("" ::: "memory")
+#if defined(x86_64) || defined(__x86_64__)
/* Pause instruction to prevent excess processor bus usage */
#define WT_PAUSE() __asm__ volatile("pause\n" ::: "memory")
-#if defined(x86_64) || defined(__x86_64__)
#define WT_FULL_BARRIER() do { \
__asm__ volatile ("mfence" ::: "memory"); \
} while (0)
@@ -154,12 +154,21 @@
} while (0)
#elif defined(i386) || defined(__i386__)
+#define WT_PAUSE() __asm__ volatile("pause\n" ::: "memory")
#define WT_FULL_BARRIER() do { \
__asm__ volatile ("lock; addl $0, 0(%%esp)" ::: "memory"); \
} while (0)
#define WT_READ_BARRIER() WT_FULL_BARRIER()
#define WT_WRITE_BARRIER() WT_FULL_BARRIER()
+#elif defined(__PPC64__) || defined(PPC64)
+#define WT_PAUSE() __asm__ volatile("ori 0,0,0" ::: "memory")
+#define WT_FULL_BARRIER() do {
+ __asm__ volatile ("sync" ::: "memory"); \
+} while (0)
+#define WT_READ_BARRIER() WT_FULL_BARRIER()
+#define WT_WRITE_BARRIER() WT_FULL_BARRIER()
+
#else
#error "No write barrier implementation for this hardware"
#endif