Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net