Re: [boost] 1.36 thread library

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-08-01 07:23:19

---------------------------
Vicente Juan Botet Escriba
----- Original Message ----- 
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 01, 2008 8:47 AM
Subject: Re: [boost] 1.36 thread library

>
> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>
>> It should be great if the Thread library documentation included a
>> History section and include the changes since 1.35 that we can already
>> found in the Version 1.36.0 page
>> (http://beta.boost.org/users/news/version_1_36_0)
>
> Good idea.
>
>> The  create_thread interface evolution is not present in the doc.
>> Replace
>>  thread* create_thread(const function0<void>& threadfunc);
>> by
>>  template<typename F> thread* create_thread(F threadfunc);
>
> Oops.
>
>> BTW, as you have enhanced the interface for the thread construction
>>
>>    template <class F,class A1,..., class An> thread(F f,A1 a1,..., An 
>> an);
>>
>> why not to apply the same schema to the create_thread function of the
>> thread_group class?
>
> There's a trac issue for that. I haven't got round to it yet.
>
>> Just one minor sugestion: The guard on the create_thread function
>> should be declared after the thread creation to limit the scope of the
>> mutex lock.
>>
>> template<typename F>
>> thread* create_thread(F threadfunc)
>> {
>>    std::auto_ptr<thread> new_thread(new thread(threadfunc));
>>    {
>>        boost::lock_guard<mutex> guard(m);
>>        threads.push_back(new_thread.get());
>>    }
>>    return new_thread.release();
>> }
>
> That's a good idea.
>
>> Reading the code we see that the thread_group class is thread safe
>> using an internal mutex. Is this is part of the contract it is not
>> documented? In addition an application creating/adding all the threads
>> of a group in one thread do not needs this thread safety. Following
>> the C++ phylosophy "don't pay for what you don't use", should't this
>> class be parameterized by a synchronization policy.
>
> Maybe. It's been thread-safe with an internal lock for as long as I've
> been aware of it though.

Surely. Maybe to be added in the todo list.

Vicente