Re: Boost.Threads - Questions

From: williamkempf_at_[hidden]
Date: 2001-08-20 07:59:07

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> [1] No atomic_t, why? A noncopyable thread needs shared_ptr, and 
shared_ptr
> needs atomic_t for thread safe reference count updates; it seems 
that
> 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.

> [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.
 
> The problem doesn't arise when I code directly to win32 or 
pthreads, which
> means that it's (possibly) a defect in the design (minimal but not
> complete.)

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.

shared_ptr<thread> p;
p.reset(new thread(f(p)));

This is, at least in theory, closer to what you currently do for both 
Win32 and pthread.

Bill Kempf