[Boost-users] [atomic] review results

Subject: [Boost-users] [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.

documentation:
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 
namespace.

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