Memory barriers in userspace? (Linux, x86-64)

Question

It is easy to set memory barriers on the kernel side: the macros mb, wmb, rmb, etc. are always in place thanks to the Linux kernel headers.

How to accomplish this on the user side?

Completion

Answer 1

You are looking for the full memory barrier atomic builtins of gcc.

Please note the detail on the reference i gave here says,

The [following] builtins are intended to be compatible with those described in the Intel Itanium Processor-specific Application Binary Interface, section 7.4. As such, they depart from the normal GCC practice of using the “__builtin_” prefix, and further that they are overloaded such that they work on multiple types.

Alp

I'm not too familiar with this topic. Is this a processor specific functionality? (Since your example is an Itanium...) – Vaticide

In general, users should not take advantage of platform- and compiler-specific functionality when there are standard, cross-platform mechanisms of achieving the same effect. What emg-2 really needs is to use the POSIX threads (pthreads) library. – Politicking

@Michael, I completely agree with your opinion. That is the reason for highlighting platform specific notes. – Alp

@Michael: the posix library does not provide mfence/sfence/lfence operations AFAIK. @nik: it is worth noting that the __sync_synchronize is broken prior to GCC 4.4: gcc.gnu.org/bugzilla/show_bug.cgi?id=36793 – Completion

Answer 2

Posix defines a number of functions as acting as memory barriers. Memory locations must not be concurrently accessed; to prevent this, use synchronization - and that synchronization will also work as a barrier.

Selfimmolation

The synchronization is not needed when all that's needed is lock and wait free one writer/one reader queue. The POSIX libraries do not provide mfence/lfence/sfence operations AFAIK. – Completion

You didn't ask for lock free operation; you asked for memory barriers in user space. POSIX has them; they are called "pthread_mutex_lock", "pthread_mutex_unlock", etc. You may not like the model behind them, but that is an official answer to your question. – Dunnite

Answer 3

Use libatomic_ops. http://www.hpl.hp.com/research/linux/atomic_ops/

It's not compiler-specific, and less buggy than the GCC stuff. It's not a giganto-library that provides tons of functionality you don't care about. It just provides atomic operations. Also, it's portable to different CPU architectures.

Strafford

Answer 4

Linux x64 means you can use the Intel memory barrier instructions. You might wrap them in macros similar to those in the Linux headers, if those macros aren't appropriate or accessible to your code

Tinny

I think this is the best option actually. The main flaw is the required maintenance of distinct compilers and past/future/non-Intel processors. – Completion

So what do you want? You don't like the portable solution, and you don't like the processor specific one. – Dunnite

Answer 5

__sync_synchronize() in GCC 4.4+

The Intel Memory Ordering White Paper, a section from Volume 3A of Intel 64 and IA-32 manual http://developer.intel.com/Assets/PDF/manual/253668.pdf

Apex

Answer 6

The Qprof profiling library (nothing to do with Qt) also includes in its source code a library of atomic operations, including memory barriers. They work on many compilers and architectures. I'm using it on a project of mine.

http://www.hpl.hp.com/research/linux/qprof/download.php4

Unstep

Answer 7

The include/arch/qatomic_*.h headers of a recent Qt distribution include (LGPL) code for a lot of architectures and all kinds of memory barriers (acquire, release, both).

Antivenin

Answer 8

Simply borrowing barriers defined for Linux kernel, just add those macros to your header file: http://lxr.linux.no/#linux+v3.6.5/arch/x86/include/asm/barrier.h#L21 . And of course, give Linux developers credit in your source code.

Connubial