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]>
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
> Good idea.
>> The create_thread interface evolution is not present in the doc.
>> thread* create_thread(const function0<void>& threadfunc);
>> template<typename F> thread* create_thread(F threadfunc);
>> BTW, as you have enhanced the interface for the thread construction
>> template <class F,class A1,..., class An> thread(F f,A1 a1,..., 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);
>> 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.