Howard Hinnant wrote:
This prints out "Success!" as it is now. But if you comment out "t.cancel()" in f2 then main hangs forever. f2 did something logically non-const to the separate thread f which in turn caused the main thread to react differently. This seems to me like f2 is doing something non-const.
I agree that a call to t.cancel() can affect the program behavior in an observable way. So can a join, even if it's considered logically const, because of its effects. So can condition::wait, even though it touches no observable state. And so can sleep. But my question is more along the lines of: why does the const/non-const label matter when we decide on the precondition and thread safety of t.cancel? If t.cancel is always valid on a valid t, this makes sharing possible and safe, regardless of whether thread::cancel is declared const.