From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-20 08:13:51
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> >  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?
> >  I have the following problem. I'm trying to create a non-local
> > 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
> > 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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk