https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Hideaki Kimura from comment #17) > Oh, is it the design of promise::get_future/set_value? > I so far don't see any reference that clarifies either way (most document > just mentions about difference between future/shared_future) It's the same rule to applies to all types in the standard library unless specified otherwise: concurrent accesses are only safe if they are all reads (i.e. const operations). Any writes (non-const operations) must be manually synchronised. get_future() is non-const, set_value() is non-const. > I'm not sure what the C++ standard says. I haven't seen a single human being > who has read it through. 30.6.4 [futures.state] says which functions are synchronised, promise::get_future() is not one of them. I'm still looking into whether there is a bug that allows the shared state to be destroyed while the call to std::call_once() is still in progress, or if that can only happen due to user error.
