Date: 2001-08-20 07:59:07
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
>  No atomic_t, why? A noncopyable thread needs shared_ptr, and
> needs atomic_t for thread safe reference count updates; it seems
> atomic_t is at the same level as boost::thread. Of course I can
hack my own
> shared_ptr using Interlocked*, but this rather defeats the purpose.
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. In any event, atomic_t is just too
difficult to define correctly and portably. It's not gone for good,
but it won't be in the initial submission. This should not be an
issue, because it's truly only an optimization.
>  I have the following problem. I'm trying to create a non-local
> shared_ptr<thread> p(new thread(f));
> _but_ I also want to pass 'p' to the newly created thread. I don't
> simple way to achieve this. In a two-phased construction design
> 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
> The problem doesn't arise when I code directly to win32 or
> means that it's (possibly) a defect in the design (minimal but not
Oh, but it is an issue for both. You just work around it.
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.
This is, at least in theory, closer to what you currently do for both
Win32 and pthread.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk