The review of Helge Bahmann's Boost.Atomic library starts today, October 17th 2011. It will end on October 26th.

I encourage everyone to participate the the discussion on the Boost mailing list about this very important library. In addition the code can be reviewed line-by-line in code collaborator (http://demo.smartbear.com/boost/)

Is there some explanation on how this works? I have created an account on that site for myself and see this Boost.Atomic review as being in progress, but it also tells me I'm not a participant. Thanks! -hg

On Oct 16, 2011, at 7:45 PM, Tim Blechmann wrote:

Hi all,

The review of Helge Bahmann's Boost.Atomic library starts today, October 17th 2011. It will end on October 26th.

I've been anxiously awaiting the inclusion of this library in Boost for some time and would like to state up front that I wholeheartedly endorse it's acceptance. That being said there are a few issues I've run into using it over the last 6 months or so... I was actually pleasantly surprised to find that the PPC atomics worked with no modifications required on BlueGene/P, at least using the gcc 4.3.2 build on my system. Unfortunately because OSX does not support unnamed semaphores, Boost.Atomic doesn't run there. I would love if the switch to named semaphores was quick and painless, but if that isn't the case it would be nice to have a compile-time warning in addition to the run-time error that occurs. The run-time error is actually relatively informative, but has still resulted in me getting a few emails from confused users. Something like: #elif defined(__GNUC__) && (defined(__APPLE__) // Warning: Unnamed semaphores not supported on Mac OS X would be helpful. A compile error would also be acceptable, but it's nice to be able to check my builds on my OSX desktop before moving code over to one of the clusters even if they won't run so I'd probably remove the error in my local copy. Using functions from libkern/OSAtomic.h would also be a valid approach rather than switching all PPC implementations to named semaphores. Support for ICC intrinsic atomics would also be most welcome, but by no means necessary. Finally, with regard to making Boost.Atomic competitive with other portable atomics libraries (because on most of the systems I work on a C++11 compatible compiler is a looooong way off), the only other one I've found to be remotely usable is OpenPA (http://trac.mcs.anl.gov/projects/openpa). It supports a variety of platforms/compilers and might be useful as far as finding out how to implement Boost.Atomic on those platforms/compilers, and the licensing is very permissive. Boost.Atomic's interface is far superior in my opinion though (thus the reason I didn't use OpenPA for my projects). With regards to interface and design I have no complaints whatsoever, I'd just like for Boost.Atomic to work on more platforms so that I can give up alternate implementations entirely! Regards, Nick Edmonds

Hi, This is my mini-review of Boost.Atomic. I didn't have much time to evaluate the library, but from what I saw this would be a most useful addition to Boost. So, my vote is "the library should be accepted to Boost". Now, to the details. I took a quick reading the docs, and here are my comments: 1. Constants BOOST_ATOMIC_CHAR16_LOCK_FREE and BOOST_ATOMIC_CHAR32_LOCK_FREE seem to be missing in the docs. 2. There seem to be no "Reference" section that describes the formal interfaces and public declarations. The "Programming interfaces" section attempts to provide this information but it would be better to have a single declaration of boost::atomic template with references to the description of its methods (pretty much what Doxygen provides). IMHO, that way the information would be more percievable. 3. It would be nice to have examples from the "Usage examples" section in a compilable form. All in all, the documentation seems to be sufficient for a more or less experienced programmer (which will probably be the user of the library) to get things started. The presence of real-world usage examples also helps a lot. Design and implementation. I did not dig into the code too much, but I can see that the implementation followed the standard quite closely. I mostly evaluated x86 part of the implementation. 1. A pity that the functional interface (i.e. atomic_* functions and atomic_* types) and the ATOMIC_FLAG_INIT and ATOMIC_VAR_INIT macros are absent. These tools might be very useful where atomics need to be statically initialized. But even without them the atomic template is very useful. 2. I would prefer the boost/atomic.hpp file to only include some headers in boost/atomic directory. Presumably, the boost::atomic template should be in the boost/atomic/atomic.hpp, and boost/atomic.hpp should include this file (along with other files, if there are any). 3. The library should probably be in the boost::atomics namespace. The atomic class template may be imported into boost namespace via using declaration. But I don't have a strong case here. 4. About gcc-x86.hpp and PIC. I believe, GCC automatically defines __PIC__ != 0 when PIC is generated, you could test for it and only save/restore ebx when needed. 5. I would really like to have a DCAS-based atomic on the x86-64 platform. I've seen the discussion on this topic, just pointing out that even though it may be slow on the current processors, things may change in future. 6. I see you use spinlock pool when no hardware support for atomic operations is available. Will this work in multi-module applications, especially on Windows? I understand that this quesion is probably better to be addressed to Boost.SmartPtr maintailer, but still... 7. Tabs should be converted to spaces and every file should end with a newline. Other than that the code looks ok. I did not compile anything though. Answering the last few questions: - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A quick reading through the docs (about an hour, I guess) and the code (around 1.5 hours). - Are you knowledgeable about the problem domain? I did implement a few lock-free algorithms and I have experience of using std::atomic and inline assembly on x86 and x86-64. I wouldn't call myself an expert though. Lastly, I'd like to thank Helge for his huge effort on bringing this library to Boost. This is a long overdue addition.

On 17/10/11 00:45, Tim Blechmann wrote:

The review of Helge Bahmann's Boost.Atomic library starts today, October 17th 2011. It will end on October 26th.

Just a few quick comments about correctness. * Operations build on top of compare_exchange (such as fetch_xor in gcc-x86.hpp) use memory_order_relaxed for all operations. Are you sure there are enough compiler memory barriers? Shouldn't you pass the supplied memory order through to the CAS call? * In gcc-ppc.h the BOOST_ATOMIC_ASM_SLOWPATH_CLEAR macro includes a 1: label, yet many of the asm blocks that use it also include a 1: label. Is this correct? * In gcc-x86.h, the platform_cmpxchg64_strong implementation assumes that T is an integral type, such that you can do (int)(desired>>32) to take the top 32 bits, and (int)desired to take the low 32 bits, which is essentially just the signed and unsigned variants of the 64-bit integer. This should therefore not be a template, but a plain inline function. cas64strong.hpp uses it incorrectly for pointers, but this specialization is unnecessary anyway --- this file is only relevant for 32-bit x86. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976