Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2011-11-01 14:08:20

On Tuesday, November 01, 2011 11:29:22 Helge Bahmann wrote:
> On Tuesday 01 November 2011 10:49:55 Tim Blechmann wrote:
> > 
> > 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

Lock-based IPC can be much more efficient than socket-based. That's not 
mentioning much more sophisticated access models to the shared data that are 
possible with shared memory. Calling sockets a drop-in replacement for shared 
memory IPC (whether it uses atomics or locks) is nonsense, IMHO.

> 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

GCC has the luxury of a shared runtime which can provide process-wide table of 
spinlocks. Boost.Atomic is header-only, so in multi-module applications this 
table has to be exported so that all modules use the single table. I mentioned 
that in the review. Do you have ideas of how to achieve that? Most obvious 
would be to link to Boost.Atomic dynamically...