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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-27 10:21:08

Howard Hinnant wrote:
> On Mar 27, 2007, at 9:45 AM, Peter Dimov wrote:
>
>> Howard Hinnant wrote:
>>
>> [ detach vs join ]
>>
>>> This is a departure from pthread semantics that I am uncomfortable
>>> with.  If I accidently get myself into this kind of race.  I think
>>> I'd
>>> prefer some noise (an assert, or exception, or crash).
>>
>> I'm not entirely sure what is the purpose of detach as it's unique
>> to N2184,
>> but if it's only used to indicate "do not cancel on ~thread,
>> please", there
>> is no need for it to actually detach anything (invalidate the
>> pthread_t
>> handle), just set a "don't cancel" flag. The race you describe is
>> then harmless.
>
> The purpose of detach is to model the semantics of pthread_detach.
> pthread_detach is described as:
>
> The pthread_detach() function is used to indicate to the
> implementation that storage for the thread thread can be reclaimed
> when that thread terminates.

This is implicit in all proposals to date. A C++ thread is always 
"detached"; if it terminates and there is no controlling object, its storage 
is always reclaimed and never leaked. There is no need for an explicit 
detach call for this to occur. The significant difference between N2184 and 
the rest is the implicit cancel on destruction, and detach disables that.

In implementation terms:

class thread
{
    pthread_t handle_;
    bool detached_;

public:

    thread(): detached_( false ) {}

    void detach() { atomic_store( &detached_, true ); }

    // (try-/timed-) 'const' joins

    ~thread()
    {
        if( !detached_ ) cancel();
        pthread_detach( handle_ );
    }
};

Is this not a conforming N2184 thread? If not, why?