From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2008-08-01 02:47:51
"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
> 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 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.
-- Anthony Williams | Just Software Solutions Ltd Custom Software Development | http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk