From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-26 14:47:14
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.