From: William Kempf (williamkempf_at_[hidden])
Date: 2001-08-20 08:50:41
>>--- 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?
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.
>> >  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
>> > simple way to achieve this. In a two-phased construction design
>> > 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
>Yes, the thought has crossed my mind, and I see that you're doing
>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
>>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.
>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.
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk