Boost Announcement :
Subject: [Boost-announce] [boost] [atomic] review results
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-07 10:41:44
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);
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.
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost-announce list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk