hello bryce, i will have a look at the code and possibly integrate the dequeue into the review version of boost.lockfree ... some comments in advance:
* boost.atomic: 128bit lockfree atomics for MSVC 2008+ (using _InterlockedCompareExchange128 and SSE2 intrinsics) and GCC-compatible POSIX compilers (using 16 byte __sync intrinsics). This code is x86-64 specific, and disabled by default. Define BOOST_ATOMIC_HAVE_SSE2 to enable in x86-64 MSVC 2008+ environments. Define BOOST_ATOMIC_HAVE_SSE2,
... atomics and sse2? how does this work together? afair, sse2 reads/writes are not even guaranteed to be atomic and both concepts are quite orthogonal ...
* boost.lockfree: A growable lockfree deque, based on algorithms by M. M. Michael. Backed by 128bit atomics. This is the first lockfree data structure I've written, so take it with a grain of salt. There's one bug that I'm aware of, unfortunately, it occurs infrequently so I haven't had much luck tracking it down.
will try to review the code and get back to you ... finding bugs in lockfree code is almost impossible to achieve via testing, but one needs to analyse it very carefully ...
P.S. I don't have a list of the specific bug fixes on hand, I'll have to go through the SVN logs for that. The only non-trivial one that I know of is the problem with intel-linux that I found and fixed (intel doesn't define *amd64* macros, and they were used for x86-64 bit detection).
it would be very helpful to see the specific diffs. only getting a tarball (or a repository without history) without knowing the branching point makes it quite time-consuming to find actual differences between your version and helge's/mine. importing your private svn repo into git via git-svn and rewriting the resulting git repository with git-filter-branch to clean the parts, which are not related to atomic or lockfree would be the cleanest way to go ... cheers, tim -- tim@klingt.org http://tim.klingt.org May music never just become another way of making money. Keith Tippett