Boost logo

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 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.
> 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, gregod at, cpdaniel at, john at