Subject: Re: [boost] [atomic] comments
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-01 05:49:55
> > 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
> > 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 ...