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/