Lots of reasons. I may not have access to all platforms, to begin with. I may not have enough knowledge about hardware capabilities of all of the platforms. Manual porting to multitude platforms may be expensive.
This is ridiculous. May I invite you to have a look at socket communication via boost.asio?
socket communication and shared memory have quite different performance characteristics. e.g. i would not trust on accessing sockets from a real-time thread.
True. But are there realistic platforms without any support of atomic ops whatsoever today? If there are, I'm not sure the library should support these platforms in the first place.
if it is not ported to the platform then nothing is avaialble. I have only recently finished sparcv9 implementation, itanium and mips still missing, so they would suffer immediately.
well, the spinlock pool uses boost::detail::spinlock (i hope no platform will rely on the fallback implementation in spinlock_nt.hpp, which seems to be simply wrong). imo, associating one with each emulated atomic<> would not be a huge memory overhead. iac, if we want boost::atomic<> to behave similar to std::atomic<> so that it works a drop-in replacement, the implementation should follow the standard as closely as possibe. in the end it would be great if someone could simply use a different namespace and maybe add/remove the BOOST_ prefix from preprocessor symbols to switch between boost.atomic and c++11 implementation ... cheers, tim