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

Subject: Re: [boost] [thread] Alternate future implementation and future islands.
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2015-03-27 17:35:57

On Fri, Mar 27, 2015 at 8:24 PM, Gottlob Frege <gottlobfrege_at_[hidden]> wrote:
> On Fri, Mar 20, 2015 at 5:19 AM, Giovanni Piero Deretta
> <gpderetta_at_[hidden]> wrote:
>> On 19 Mar 2015 19:51, "Niall Douglas" <s_sourceforge_at_[hidden]> 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