Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at