From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-26 15:24:12
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-
>> 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);
> 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
>> Why does the const/non-const label matter when we decide on the
>> 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?
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk