Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-07-02 10:40:02

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> 
> [...]
> 
> > 4) Creation within a loop and join all.
> [...]
> > void foo()
> > {
> >    thread::ref threads[10];
> >    for (int i=0; i<10; ++i)
> >       threads[i] = thread::create(&bar);
> >    for (int i=0; i<10; ++i)
> >       threads[i]->join();
> > }
> 
> An alternative:
> 
> void foo(int n)
> {
>     std::vector<thread::ref> threads; // reserve(n) possible
> 
>     for(int i = 0; i < n; ++i) threads.push_back(thread::create
(&bar));
> 
>     thread::join(v.begin(), v.end()); // iterator version
> }
> 
> [...]
> 
> > It appears to me that the thread ref concept is more efficient in
> > only a couple of usage patterns, and then only theoretically, with
> > most implementations probably producing identical results, or
> > actually favoring the thread concept.
> 
> The main goal of the thread::ref design is not to beat the 
noncopyable
> thread in efficiency. Its goals are to match it in efficiency and 
surpass it
> in other areas, like being easier to use, less error prone, and 
integrating
> well with the STL and other similar libraries that like lightweight 
copyable
> objects [who doesn't?].
> 
> You don't look convinced that a handle/body based design is easier 
to use,
> though.

I'm not.  The only example given by either of us that indicates more 
ease of use is the example you just gave with a vector.  However, we 
deal with this all the time in C++ using a smart pointer, and the 
ease of use with a smart pointer is nearly identical even if the 
overhead becomes a wash again.  In fact, the thread ref concept is 
just a variation on a smart pointer!

Bill Kempf