Re: [boost] Re: Boost.Threads - Questions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-20 08:13:51

From: <williamkempf_at_[hidden]>
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > [1] No atomic_t, why?
>
> No, ref-counting can be done via mutex instead of atomic integer
> operations.  In fact, there was some compelling arguments given to me
> that that's what should be done.

Interlocked* is much more efficient, is it not?

> > [2] I have the following problem. I'm trying to create a non-local
> thread
> > object:
> >
> > shared_ptr<thread> p(new thread(f));
> >
> > _but_ I also want to pass 'p' to the newly created thread. I don't
> see a
> > simple way to achieve this. In a two-phased construction design
> this is
> > trivial:
> >
> > shared_ptr<thread> p(new thread); // creates a 'detached' thread
> object
> > p->create(bind(f, p)); // create the thread and associate it with *p
> >
> > Of course two phased construction is evil.
>
> Not when it suits a design.  It's evil as far as the library
> interface is concerned, but your user code can trivially make use of
> two phase construction to achieve what you want here.  How?  Pass "f"
> a parameter that includes a monitor construction which the thread
> waits for.

Yes, the thought has crossed my mind, and I see that you're doing something
along those lines already. However I think that the complexity of the
solution does not match the problem, which - at least to me - indicates a
problem with the design.

> While I'm thinking about it, there's an even easier method for doing
> this.  It creates a minor race condition, but the race may not matter
> depending on what you're trying to accomplish here.
>
> shared_ptr<thread> p;
> p.reset(new thread(f(p)));

It's exactly the race condition I want to avoid.

--
Peter Dimov
Multi Media Ltd.