Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-07-02 13:04:06

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> 
> 
> > --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> 
> > > If you expand the examples that had a thread_manager or a
> > thread_group in
> > > them, giving the full implementation, you'll see that they, too,
> > demonstrate
> > > the same point.
> >
> > No, they don't, actually.  Any difficulties in use (minimal) are
> > eliminated by the other concepts.
> 
> Let's get back to your original example:
> 
> void foo()
> {
>    thread_group threads;
>    for (int i=0; i<10; ++i)
>       threads.create(&bar);
>    threads.join_all();
> }
> 
> Here's an implementation of thread_group:
> 
> class thread_group
> {
> public:
> 
>     // all implicit members are fine and useful
> 
>     template<class F> void create(F f)
>     {
>         v_.push_back(thread::create(f));
>     }
> 
>     void join_all()
>     {
>         thread::join(v_.begin(), v_.end());
>     }
> 
> private:
> 
>     std::vector<thread::ref> v_;
> };
> 
> As you can see, it's very similar to my vector example.

There are two problems here.  First, as I pointed out the details are 
hidden in the other concept, so the ease of use is not impacted.  
Second, you chose to use a ref-count design internally, when such a 
design is not needed.

class thread_group
{
public:
    // all implicit members are fine and useful

    template<class F> void create(F f)
    {
        v_.push_back(new thread(f));
    }

    void join_all()
    {
        std::vector<thread*>::iterator it = v_.begin();
        while (it != v_.end())
        {
           (*it)->join();
           it = v_.erase(it);
        }
    }

private:
    std::vector<thread*> v_;
};

You should note that like you I didn't include proper 
synchronization, so this implementation isn't valid, but it 
illustrates the point.  My implementation required no reference 
management, only explicit lifetime management.

> > > So, your unspoken question is probably "why provide a 
thread::ref
> > when we
> > > already have shared_ptr?"
> >
> > No, that's not really the issue.  Ref-counting is the exception, 
not
> > the rule, to the need for lifetime management.  Explicit 
ownership is
> > the norm, which is also much more efficient.
> 
> Is it really your opinion that explicit management is the norm in 
modern
> C++?

No, but for some object types and usages, yes, then it is the norm.  
The usage patterns for a thread concept dictate that the norm is 
going to be explicit management.  That is my claim.

For C++ in general, I'd say that neither is the norm.  That's why we 
have both auto_ptr and shared_ptr in our tool box.
 
Bill Kempf