Subject: Re: [boost] [thread] Alternate future implementation and future islands.
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-29 10:50:56
On 27 Mar 2015 at 21:35, Giovanni Piero Deretta wrote:
> > Just to be clear, my non-allocating promise/future was meant to be
> > more of a proof-of-concept, not necessarily optimal efficiency.
> > I would need to recheck, but I think most of it requires only acquire
> > or release, not full sequential consistency, if that helps. I rarely
> > write anything that requires full sequential consistency.
> Hum, I do not think you can implement it with just plain load and
> stores, I think you need at least one RMW there. Probably acq_rel is
> enough for that, but that's no less expensive than seq_cst on x86.
To the hardware yes. To the compiler no - acquire-release allows very
significantly wider scope for optimisation.
In my earlier benchmarking of test implementations, a CAS lock for
each of the future and promise turned out to be faster than any other
technique on non-transactional compilers. I had std::lock do the
locking of both future and promise before modification.
One could make that faster probably, but the ordering is tricky to
make bug free, and I suspect maintenance would be expensive.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk