Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Tim Blechmann (tim_at_[hidden])
Date: 2011-11-01 07:59:09

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

imo, `fallback' would mean that i can still compile the program, without the 
need to provide a different implementation for the case that atomics are not 
lockfree/interprocess safe.

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

life would be so much easier for me, if the users of my software would not run 
on off-the-shelf operating systems ;)

> 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

well, i'd say this is a problem of gcc's implementation of std::atomic. this 
doesn't justify that boost.atomic does not follow the suggestion of the 
standard.

cheers, tim