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