Re: [boost] [atomic] comments

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 
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