Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at