Atomic memory update operations
Provides implementations for atomic memory update operations on a
number of architectures. This allows direct use of these in reasonably
portable code. Unlike earlier similar packages, this one explicitly
considers memory barrier semantics, and allows the construction of code
that involves minimum overhead across a variety of architectures.
There are two kinds of entities in this directory:
- Subdirectories corresponding to specific compilers (or compiler/OS combinations).
Each of these includes one or more architecture-specific headers.
- More generic header files corresponding to a particular ordering and/or
atomicity property that might be shared by multiple hardware platforms.
This package provides semi-portable access to hardware provided
atomic memory operations. These might allow you to write code:
- That does more interesting things in signal handlers.
- Makes more effective use of multiprocessors by allowing you to write
clever lock-free code. Note that such code is very difficult to get
right, and will unavoidably be less portable than lock-based code. It
0) If possible, do this on a multiprocessor, especially if you are planning
on modifying or enhancing the package. It will work on a uniprocessor,
but the tests are much more likely to pass in the presence of serious problems.
1) Type ./configure --prefix=<install dir>; make; make check
in the directory containing unpacked source. The usual GNU build machinery
is used, except that only
The libatomic_ops_gpl includes a simple almost-lock-free malloc implementation.
This is intended as
Note that the AO_stack implementation is licensed under the GPL,
unlike the lower level routines.
Most of the atomic_ops functionality is available under Win32 with
the Microsoft tools, but the buil
2008-02-11 Hans Boehm <Hans.Boehm@hp.com>
(Really Ian Wienand & Debian maintainers)
Originally written by Hans Boehm, with some platform-dependent code
imported from the Boehm-Demers-W
Browse inside libatomic_ops-devel-1.2-8.gc.1.el6.x86_64.rpm