Re: [boost] Lightweight futures (was: Re: Final lightweight monad, next gen futures and upcoming AFIO review

Subject: Re: [boost] Lightweight futures (was: Re: Final lightweight monad, next gen futures and upcoming AFIO review
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2015-07-03 17:28:49

On Thu, Jul 2, 2015 at 10:26 PM, Niall Douglas
<s_sourceforge_at_[hidden]> wrote:
> On 2 Jul 2015 at 14:26, Gottlob Frege wrote:
>
>> But without looking at all the code, I'm not sure who/what/when
>> _needs_locks ever changes.  Assuming both the promise and the future
>> side READ it, and one of them can WRITE it, then the writer needs a
>> release on setting, and the other side needs an acquire on every read.
>> If only one side can set, the setter side never needs anything beyond
>> the release, and only needs release after the other side has gone off
>> onto its own thread.
>
> That facility is disabled by default now. It always locks in the APIs
> documented "SYNC POINT".
>
>> As for multiple threads reading the future: No.  IIUC, std::future
>> isn't thread-safe on its own.  It can only be used by one thread
>> (without extra external synchronization).  It only guarantees no data
>> races relative to the other thread holding the promise, not to other
>> threads trying to read the same future.
>
> This surprises me.
>

Anything else would surprise me.  I guess I better go read the
standard though, to be sure...

    30.6.6 Class template future

    2 [ Note: Member functions of future do not synchronize with
themselves or with member functions of
shared_future. —end note ]

It is a non-normative note, but I suspect that is because the default
throughout the standard is that everything is unsynchronized. So they
don't need to say anything normative to say that future get() is
unsynchronized, but just to be sure, they included a note.

> As you saying that if two threads try to get() from a future
> concurrently, that both may succeed due to racing?
>

Or your cat could get pregnant.  ie Undefined Behaviour.

> I had thought that exactly one succeeds and exactly one will receive
> a no_state exception throw?
>

UB.

I could still be wrong.  There might be other parts that say
otherwise, but I couldn't find them.  We could ask the committee I
suppose.

Tony