Re: Draft of generation 2 thread class

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 
techniques
> >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 
as
> >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 
heap 
> 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 
protect 
> the count. There probably won't be much contention for the counts, 
so 
> 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