On Thu, Jul 2, 2015 at 10:26 PM, Niall Douglas
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