Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-20 15:13:33

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "bill_kempf" <williamkempf_at_h...>
> > --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > > 2. disable_cancellations would be much more useful if it 
specified 
> > that
> > > threads are disabled as long as one of these objects exists, as 
> > opposed to
> > > restoring the state to the previous setting upon destruction. I 
can 
> > imagine
> > > that there may be uses for disable_cancellation objects in 
dynamic 
> > memory.
> > > Would it affect efficiency much to make this change?
> > 
> > Hmmm... interesting thought.  Means ref-counting, but as long as 
> > these instances aren't shared between threads (and they shouldn't 
be) 
> > this isn't going to effect the speed much at all.  I can't 
envision 
> > the scenario in which this would actually be useful, but I'm not 
> > adverse to considering it.  Some further discussion about this 
would 
> > be very welcome.
> 
> No, this doesn't actually mean ref-counting (in the usual sense.)
> 
> It simply means that currently we have
> 
> disable_cancellations(): old_state_(setcancelstate(disabled)) {}
> ~disable_cancellations() { setcancelstate(old_state_); }
> 
> whereas Dave's version is:
> 
> long tls_cancel_state = 0;
> 
> disable_cancellations() { ++tls_cancel_state; }
> ~disable_cancellations() { --tls_cancel_state; }
> 
> AFAICS.
> 
> Makes sense to me. It's like ::ShowCursor() in Win32.

That's precisely what I meant by ref-counting.  If there's a 
different term that applies I'd love to know what it is and how the 
two concepts differ.

Bill Kempf