Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-11-01 14:29:50

On Tuesday 01 November 2011 19:08:20 Andrey Semashev wrote:
> 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.

Well then create a shared memory region and use explicit locking. This is even 
more efficient than the many implicit locks in miniscule atomic objects.

See, by *not* exporting the spinlock of the fallback path of atomic<> objects 
I just made your IPC even more efficient.

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

the same way shared_ptr treats its spinlock pool (template specialization, and 
I guess this leads to a symbol with virtual linkage, the instances all of 
which are collapsed into a single instance by the run-time linker)

Best regards
Helge