https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #24 from Leon Timmermans <fawaka at gmail dot com> --- (In reply to Jonathan Wakely from comment #18) > (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 can see your point from a C++ point of view, but this doesn't make sense from a usable threading point of view. IMHO, the whole point of abstractions such as promises is to isolate the user from such issues. Leon
