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

On Fri, Mar 27, 2015 at 8:24 PM, Gottlob Frege wrote:

On Fri, Mar 20, 2015 at 5:19 AM, Giovanni Piero Deretta wrote:

...

On 19 Mar 2015 19:51, "Niall Douglas" wrote:

...

On 19 Mar 2015 at 18:05, Giovanni Piero Deretta wrote:

[snip]

...

...

Anyways, the plan is to add support to a custom allocator. I do not

think

...

...

you can realistically have a non allocating future *in the general case* ( you might optimise some cases of course).

We disagree. They are not just feasible, but straightforward, though if you try doing a composed wait on them then yes they will need to be converted to shared state. Tony van Eerd did a presentation a few C++ Now's ago on non-allocating futures. I did not steal his idea subconsciously one little bit! :)

I am aware of that solution My issue with that design is that it require an expensive rmw for every move. Do a few moves and it will quickly dwarf the cost of an allocation, especially considering that an OoO will happily overlap computation with a cache miss, while the required membar will stall the pipeline in current CPUs (I'm thinking of x86 of course). That might change in the near future though.

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. -- gpd