Matthew Chambers wrote:
That's too bad. It seems reasonably stable now for my platforms (x86[_64] Windows/Linux)
Matt, how have you measured the stability? One of my main concerns with Atomic is that it seems to lack any tests, so it is hard to know whether it is actually working correctly or not. (Doing the correct operation but non-atomically, or without the required memory barriers, would often appear to work perfectly.) We use fifo/queue in our command-line multithreaded analysis software. My measure of stability is
On 7/26/2011 11:54 AM, Phil Endecott wrote: that we don't get any mysterious crashes or aberrant results compared to when we used lock-based synchronization. :) Like any thread-safety issue, it's practically impossible to prove something is correct through testing. But you make a good point that Boost.Atmoic should have some tests that at least try to stress its correctness.
But: my suspicion is that it is now too late for Boost.Atomic to be useful. g++ already seems to have its own std::atomic implementation (since 4.4 apparently). With the impending ratification of C++0x we can surely expect Microsoft and LLVM to have their implementations ready soon (apparently LLVM says "The only major missing piece of C++'0x support [in libc++] is <atomic>". So by the time a group of replacement maintainers got their acts together, they/we might only be maintaining Boost.Atomic for the benefit of a few people who are unable to use newest compilers. That wouldn't motivate me much. I too disagree with this. It will be many years before many (important) projects even consider moving to C++1x. And as with many features (regex, filesystem, thread, etc.), having C++1x features in boost that work with old compilers is a great way to play with them and wet feet without making a big leap.
-Matt