If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted.
That seems unnecessary. Can't Boost.Lockfree simply include (a version of) Boost.Atomic as an implementation detail for now?
this would somehow mean to fork boost.atomic, move everying to a `namespace detail'. might introduce some maintenance overhead to keep it in sync with the original library.
Excuse me if it's common knowledge around here, but I've seen several libraries relying on boost.atomic that have been reviewed, so may I ask : why haven't Boost.Atomic been reviewed yet? It looks like it's already finished and reliable...
mainly because the original author did not submit it. nor has he been very active during the last few months: the boost.lockfree repository contains some fixes to boost.atomic, which haven't been applied to the upstream repository, although i have sent them the author. cheers, tim