Re: [boost] [atomic] comments

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

On Monday 31 October 2011 23:30:19 Tim Blechmann wrote:
> > > > I think, having a mutex per atomic instance is an overkill. However,
> > > > a
> > > > spinlock per instance might just be the silver bullet. The size
> > > > overhead should be quite modest (1 to 4 bytes, I presume) and the
> > > > performance would still be decent. After all, atomic<> is intended
> > > > to be used with relatively small types with simple operations, such
> > > > as copying and arithmetics. In other cases it is natural to use
> > > > explicit mutexes, and we could emphasise it in the docs.
> > >
> > > might be possible, the problem is that this assumes that there is
> > > atomic<something> available -- as soon as you hit a platform where
> > > everything hits the fallback, you just have to use a mutex and the cost
> > > becomes unbearable
> >
> > True. But are there realistic platforms without any support of atomic ops
> > whatsoever today? If there are, I'm not sure the library should support
> > these platforms in the first place.
>
> well, it is quite a chicken-and-egg problem, we need atomics to implement
> atomics to implement atomics, when atomics are not available. but in the
> real world i guess all platforms will provide some kind of atomic
> operations, which are sufficient to implement basic spinlocks.
>
> it would also be fine with me to delegate the implementation to
> boost::detail::spinlock in the smart_ptr library (assuming that it will
> never be implemented via atomic<>)

I think that it might long-term be worthwhile to consider formulating 
smart_ptr in terms of atomic<> -- moving the existing spinlock pool from one 
place to another would be a relatively trivial change.

Best regards
Helge