Re: [boost] [atomic] comments

Subject: Re: [boost] [atomic] comments
From: Helge Bahmann (hcb_at_[hidden])
Date: 2011-10-31 10:01:35

On Sunday 30 October 2011 17:45:18 Tim Blechmann wrote:
> hi helge,
>
> > > shared memory support:
> > > the fallback implementation relies on the spinlock pool that also used
> > > by
> > > the smart pointers. however this pool is per-process, so the fallback
> > > implementation won't work in shared memory. can this be changed/fixed?
> >
> > fixing this would require a per-variable lock... depending on the
> > platform this can have enormous overheads.
>
> i've checked N3225, the most recent version of the draft that i have at
> hand at the moment. 29.4.4 tells me:
>
> The implementation should not depend on any per-process state. This
> restriction enables communication by memory that is mapped into a process
> more than once and by memory that is shared between two processes.
>
> cheers, tim

but "should" != "must", and additionally:

a) IMHO atomics for inter-process coordination is the exception, while 
inter-thread coordination is the norm

b) "per-object" lock is expensive (sizeof(pthread_mutex_t) can be 40 bytes)

c) when you hit the fallback path, then you are better off using a 
datastructure with locking to begin with

*If* I change the implementation to a per-object lock then this would in my 
view mean to optimize for an uncommon case, with noticable memory overhead 
penalties for the common case, to allow using the atomic objects as "drop-in" 
replacements in an environment where they are not the best solution anyways. 
(I would favor to move the distinction between using atomic objects for a 
given data structure versus locking upwards, instead of moving everything 
downwards and shoe-horning it into boost.atomic).

I have serious difficulties justifying such a change, maybe others can offer 
their opinion?

Best regards
Helge