Re: Draft of generation 2 thread class

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-19 14:08:32

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> 
> > > either. Even if people behave the way you like and keep the 
object
> > off the
> > > heap, there's no reason they can't touch it across threads. 
This is
> > a simple
> > > case where it costs nothing to specify a more robust 
implementation.
> >
> > It's not very controversial.  As I stated in another thread I just
> > want some discussion about whether such usage can just lead to 
other
> > errors/abuses by the user and whether there's any valid reason for
> > using the technique in the first place.  The specification isn't 
more
> > robust if it leads to other errors/abuses with out adding any 
actual
> > benefit.
> 
> Okay, maybe I should think about this. Turning off cancellation 
just lets
> you call cancellation points without causing an exception. The only 
reason I
> can think of to do this is to ensure an exception guarantee for an
> operation. The only reason I can think of to give the object a 
lifetime
> which is not synchronized with the heap would be so that 
cancellation might
> be turned off or on in the middle of an operation. Okay, the 
scenario goes
> like this: you have a long-running operation which must provide the 
strong
> guarantee. During the first part of the operation, it's okay to 
throw an
> exception, because the original data is still recoverable. As soon 
as the
> original data is first modified, the operation must run 
successfully to
> completion, so you have to turn off cancellation. Cancellation 
needs to be
> turned off in an inner loop and remain off until the operation 
completes.
> 
> Not hugely compelling, but plausible IMO.

Yes, plausible, but I don't see how this scenario requires a heap 
based approach.

void operation()
{
  // initial stuff
  {
     disable_cancellation protect;
     // loop
  }
  // other stuff
}

Can you illustrate what you were thinking in code?

Bill Kempf