Howard Hinnant wrote:
On Mar 26, 2007, at 2:47 PM, Peter Dimov wrote:
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.
I guess my answer would go back to this snippet:
void foo(const thread& t);
void bar() { std::thread t(f); ... foo(t); ... }
Because of the const qualifier on the thread& which foo takes as a parameter, and knowing that the const interface of thread is a subset of the non-const interface, we can make useful assumptions about t after the call to foo() (such as t hasn't been canceled).
I agree that knowing that thread::cancel is declared non-const allows this code to reason that foo does not invoke t.cancel. But that is not what I'm asking.
Why does the const/non-const label matter when we decide on the precondition and thread safety of t.cancel?
Or, stated differently, Why should a thread::cancel that is declared non-const necessarily be made thread and sharing unsafe?