|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-20 09:05:21
From: "William Kempf" <williamkempf_at_[hidden]>
> >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.
Herb Sutter has some measurements at http://www.gotw.ca/gotw/045.htm that
seem to indicate that the win32 atomic primitives beat a critical section by
orders of magnitude in some cases.
> 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.
The question I asked was "what are the reasons for not including atomic_t?",
not "do reasons exist?" or "will this be the way it's going to be?"
Why force users to roll their own atomic_t? They will.
> 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.
OK, I see. Thanks.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk