Boost logo

Boost :

Subject: [boost] [atomic] review results
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-07 10:41:44

hi all,

unfortunately only few reviews of boost.atomic arrived in time, however i
count 3 YES and no NO, so i am happy to say:

    Helge Bahmann's boost.atomic library is ACCEPTED.

since the library is an implementation of a c++11 feature for c++03, design,
API and semantics are mostly fixed. many comments are going into details of
the implementation, so i won't sum them all up ... iac, helge already said he
wants to address the raised issues, the main points are summarized below.

full implementation of the c++11 interface:
the library currently only implements a subset of the c++11 library. it lacks
the functional interface for integral atomic types and the ATOMIC_VAR_INIT /
ATOMIC_FLAG_INIT macro. quickly consulting the latest draft that i currently
have at hand the following two functions are missing as well:

template <class T> T kill_dependency(T y);
void atomic_signal_fence(memory_order);

i encourage helge to provide a full implementation of the interface.

the documentation is currently lacking a good API reference. i would therefore
encourage helge to provide a doxygen-generated reference section. there were
some concerns that it assumes that readers will have to be familiar with
concurrency. maybe it is a good idea to point to some literature/tutorials
about concurrent programming and/or to c++11 atomics.
the section of real-world examples could probably include a link to
shavit/herlihy's book `the art of multiprocessor programming'.
it would also be helpful to have a detailed specification, if a
platform/compiler combination supports a specific type natively (with run-time
dispatching or specific compiler flags) ... maybe in form of a table.

shared memory support/multi-module support:
in multi-module applications and when using shared memory, the blocking
emulation of atomics can cause troubles. for multi-module applications this
can be resolved by placing the spinlock pool inside a shared library. shared-
memory support could be realized by associating a (spin)lock with each
blocking atomic<> instead of using a pool of spinlocks. boost should
definitely provide atomics which support shared memory, either by default or
by an additional implementation which is placed in the boost::interprocess

i would like to thank helge for implementing boost.atomic and submitting it to
boost and everyone who participated in the review.

cheers, tim
review manager

Boost list run by bdawes at, gregod at, cpdaniel at, john at