LWN: Comments on "Toward generic atomic operations"

Toward generic atomic operations

scientes — Thu, 09 Aug 2012 05:51:17 +0000

Since Linux 3.1 (or Linux 2.6.30 with armv6k or later) and gcc 4.7, ARM supports the same 8 byte atomic operations as x86 does,(using the __kernel_cmpxchg64 syscall) so hardware doesn't really get in your way. (armv6k+ cpus do this much faster however)

Toward generic atomic operations

mpr22 — Wed, 08 Aug 2012 09:18:24 +0000

ISTR running into a problem where store-conditional appeared to be behaving as "store if there is a currently valid reservation" rather than the desired "store if the destination address is the target of the currently valid reservation".

Toward generic atomic operations

sdalley — Tue, 07 Aug 2012 14:18:08 +0000

The first instruction, often called load-with-reservation, load-exclusive, or load-link, atomically loads the value of a given memory location into a register and marks that memory location as reserved.

The loaded value can then be manipulated arbitrarily before a second instruction, often called store-exclusive, or store-conditional, atomically stores an updated value from a register back to a given memory location, provided that no modification has been made to that memory location in the interim.

...In every case, outstanding reservations are invalidated upon a context switch between running tasks (often as a result of a specific invalidation in the context-switch code)....

Why do we need the last bit? Surely you don't want to invalidate reservations willy-nilly - the pre-empting task may have nothing to do with the one being pre-empted and therefore be no danger to it. Maybe a task kicked off by unrelated network activity, etc, etc. If it is actually contending, it will also be attempting a reservation and will fail/loop at that point anyway?

Toward generic atomic operations

nix — Sat, 04 Aug 2012 11:58:42 +0000

Excellent news! The mangling change proposed in the mail you link to seems ever so much better than a silent ABI change.

(And, gosh, that's embarrassing: the revert, like the implemntation, was done by my own co-worker just last month and I didn't notice until I made a fool of myself in this thread. I must pay more attention!)

Toward generic atomic operations

jwakely — Fri, 03 Aug 2012 13:25:46 +0000

The std::list incompatibility has been reverted, so only GCC versions 4.7.0 and 4.7.1 are incompatible with other versions. The same releases had an ABI bug with passing std::pair, which has also been fixed now. There are some other differences still that result in (mostly harmless) ODR violations. The new plan is to implement custom attributes that affect name mangling to allow C++03/C++11 interoperability, see http://gcc.gnu.org/ml/gcc/2012-07/msg00100.html

Toward generic atomic operations

jcm — Fri, 03 Aug 2012 03:34:13 +0000

Like I said, there are implementations already that you can install (there's also been stuff in P99, and Google turns up others, like your example), and I noted that GCC has built-ins for atomics. I didn't go into the older implementation that wasn't universal for every architecture and wasn't used by end applications because that wasn't really its purpose. C11 by contrast isn't a hack, it's a standard that is supposed to be used universally.

Anyway, thanks for the feedback!

Toward generic atomic operations

wahern — Fri, 03 Aug 2012 01:59:16 +0000

I realize that this is Linux Weekly News, but since when was Linux the only platform with pthreads support? Heck, even Windows has pthreads-win32. The only platform I know of with broken pthreads is OpenBSD, which is going through a messy transition from user threads to 1:1 pre-emptive threading. (I say broken because some signal handling is presently fubar.) The reason people roll their own threading library isn't because they want to be portable to non-Linux, it's because they want to be "portable" to Windows. That's a tremendous distinction. (Also, it's because rolling your own threading API is one of those low-level tasks that's enticing to people who still think of C as a high-level assembler, aching to be abused.)

And, unless I'm mistaken, both GCC and clang have the capability to support <stdatomic.h>, they just don't ship with that header. But all the way back to GCC 4.1'ish (an eternity ago), GCC has had atomic primitives, based on a proposed Intel specification and which bares more than a passing resemblance to the C11 and C++11 API. If you want <stdatomic.h> you can find an implementation based on GCC and clang intrinsics here,

http://svnweb.freebsd.org/base/head/include/stdatomic.h?v...

I'm not sure if it's 100% complete, but for all the basic stuff (increment, store, load, compare-and-swap), it should suffice.

Toward generic atomic operations

nix — Thu, 02 Aug 2012 23:30:15 +0000

Of course, this incompatibility is only apparent in the STL. So I suppose one could write a non-STL-using atomic-ops translation unit that just did atomic stuff and didn't go near the STL, then *just* compile *that* as C++11. It should link to C++98 stuff without any trouble, and the resulting binary should work even if the C++98 stuff uses the STL, as long as you don't specify C++11ness at link time.

Toward generic atomic operations

nix — Thu, 02 Aug 2012 23:28:50 +0000

... as long as you don't mind using C++11. Which is ABI-incompatible with C++98. This is often going to be a bit of a problem.

Toward generic atomic operations

jonabbey — Thu, 02 Aug 2012 17:02:21 +0000

Great essay, thanks.

What about C11 atomics in clang/LLVM?

jnareb — Thu, 02 Aug 2012 16:53:35 +0000

Does clang compiler (the C compiler of LLVM project) support stdatomic.h from C11 standard?

Toward generic atomic operations

tvld — Thu, 02 Aug 2012 14:40:56 +0000

GCC 4.7 already has experimental support for C++11 atomics, including the front-end bits. So if you have a C++ program, you can already use the new atomics.

Toward generic atomic operations

tvld — Thu, 02 Aug 2012 14:37:39 +0000

Also note that the atomics are just a part of the memory model. Using libatomic-ops, for example, does not guarantee that your compiler actually adheres to the memory model (e.g., does not introduce speculative stores that could be data races in a multi-threaded execution). There are different opinions about whether the C++11/C11 memory model should be the default even for non C++11/C11 compilations. IMO, this would be A Good Thing; other people are worried about potential performance disadvantages for single-threaded programs.

Toward generic atomic operations

jcm — Thu, 02 Aug 2012 07:42:20 +0000

Good points. The intention here is not to advocate for "proprietary extensions", but on some level I'm saying that if a project relies upon GCC, it's worth just considering using their existing atomics rather than re-implementing the wheel with inline assembly. An preferred alternative is to use an existing library, but that is not always possible. I just reviewed some of the Fedora ARM codebase for inline assembly and this kind of stuff showed up way more than I expected. It's something that needs fixing. I hope C11 is quickly adopted as means to do so.

Toward generic atomic operations

kev009 — Thu, 02 Aug 2012 05:23:08 +0000

Some of the tips in this article are pretty cavalier. Notably, until C11 is common enough to be required by a project, one _SHOULD_ use a library like libatomic_ops (from Boehm GC) for these operations and NOT proprietary compiler extensions.

Toward generic atomic operations

jcm — Thu, 02 Aug 2012 03:15:38 +0000

In case anyone wonders why 47 is the one true magic number...

http://www.youtube.com/watch?v=SPoiH0JlQ9A

Jon.

Toward generic atomic operations

jamesd — Thu, 02 Aug 2012 03:06:45 +0000

In case people aren't grokking "make Star Trek fans happy", this https://plus.google.com/106265217227408958782/posts/3FrbN...