Boost logo

Boost :

Subject: Re: [boost] Lightweight futures (was: Re: Final lightweight monad, next gen futures and upcoming AFIO review
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-02 22:26:47

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.

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

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


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at