Re: Boost.Threads - Questions

From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-20 08:50:41

>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?

More efficient, yes.  Much more... maybe, maybe not.  Regardless, there's 
valid reasons to not include atomic integer operations in the initial 
submission, and that's simply the way it's going to be.

>> > [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.

The only other solution is to allow threads to be created in a "suspended" 
state and to "resume" them only when you've set the state, which is just a 
built in version of what I suggested.  Suspending and resuming threads is 
problematic and I chose to initially not include this functionality.  Since 
you can accomplish the same thing manually this results in a "minimal yet 
complete" 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.

Then you need synchronization via a "monitor", whether this is built in or 
done manually.  For now, do it manually.  In your case it's going to be 
encapsulated any way, so it's not really an issue.

Bill Kempf

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp