Boost logo

Boost :

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
> (

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);


> 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.


Anthony Williams            | Just Software Solutions Ltd
Custom Software Development |
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Boost list run by bdawes at, gregod at, cpdaniel at, john at