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. but it might be a possibility, if boost.atomic won't be reviewed in the near future. but if this won't be the case, maybe some people can join their effort to adopt boost.atomic, if the original author won't have time to do the review. imo this would be reasonable, because the library will hopefully have a short lifespan. it will be obsolete, when most compilers provide c++0x atomics. tim