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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-03-26 13:53:14

On Mar 26, 2007, at 12:44 PM, Peter Dimov wrote:

> Howard Hinnant wrote:
>
>> Do we want such sharing *implicitly*?  By default?  In the
>> *foundation* class?
>
> There is a difference between not wanting sharing implicitly by  
> default and
> actively not supporting it by making all operations non-const and  
> not thread
> safe.

Fair point.  Perhaps we should go back to a more fundamental question:

std::thread t(f);
...
t.cancel();  // Logically is this a const or non-const operation on  
the thread executing t/f?

To answer that question probably involves the very definition of  
cancellation.  The "t.cancel()" can reasonably be interpreted in two  
different ways:

1.  Owner to t:  I'm no longer interested in your computation (but  
somebody else might be).
2.  Owner to t:  I want you to clean-up and stop as soon as possible.

I believe the shared ownership handle will actually have to support  
both semantics (the first belongs in the handle's destructor).  The  
sole ownership handle outlined in N2184 (directly) supports only the  
second interpretation.  And the second interpretation seems to me to  
be a non-const operation on t.  It must set thread state in t (either  
external or internal to the OS thread).

void foo(const thread& t);

void bar()
{
     std::thread t(f);
     ...
     foo(t);
     ...
     // Is it useful to be able to assume things about t here?  For  
example:
     //    t hasn't been canceled, or moved from.
     // Perhaps foo() tested t's identity or queried it for a pending  
cancellation
}

-Howard