Re: [boost] [thread] Alternate future implementation and future islands.

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/