Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk