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? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/