Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-11-01 06:29:22

On Tuesday 01 November 2011 10:49:55 Tim Blechmann wrote:
> > > 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.

is there some semantic ambiguity to the word "fallback" that escapes me? or do 
you expect the "fallback" to have the same performance characteristic as 
the "optimized" implementation, always? then please explain to me how a 
fallback for atomic variables using locks is going to preserve your expected 
performance characteristics

> e.g. i would not trust on accessing sockets from a 
> real-time thread.

what makes you believe that message channels in real-time systems were 
designed so dumb as to make them unusable for real-time purposes?

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

right, but the standard implementation for gcc does not use a spinlock per 
object (see __atomic_flag_for_address) which turns all of this moot - there 
is NO guarantee for std::atomic to be safe interprocess, period