Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-20 15:06:53

--- In boost_at_y..., Tom Becker <voidampersand_at_f...> wrote:
> On Sat, 19 Jan 2002 12:02:12 -0500, "David Abrahams"
> <david.abrahams_at_r...> wrote:
> >I wasn't. If you're going to make it unsafe to put them on the
heap, we
> >should prevent dynamic allocation, but the big problem with those
> >is that none of them prevent you from embedding the object in
another one
> >which is allocated on the heap (a /very/ likely case). I take this
> >another strong argument against making it do state-restoration
instead of
> >counting.
> This is the primary argument for having the disable_cancellation
> class use counting. I can't think of any other arguments that are
> very compelling. Allocating disable_cancellation objects on the
> is not something that I would do. But if we can make the class
> absolutely bullet-proof for all possible uses, no matter how wacky
> they may be, and it's at a low cost, that's the way to go.
> In order to support counting safely, it will need a mutex to
> the count. There probably won't be much contention for the counts,
> a single global mutex for all the counts might be enough. Actually,
> if you can use atomic increment and decrement, you might not even
> need a mutex. Either way, that seems like a very small price to pay
> for eliminating a potential failure mode.

I am totally against making this class thread safe. The cost of
synchronizing the ref-count is simply to high for this low level
concept when usage across thread boundaries is a very bad idea even
with synchronization.

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at