Re: [boost] Boost.Threads, N2178, N2184, et al

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-
>> 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?