Boost logo

Boost :

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


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