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