Re: [c++-pthreads] Re: thread-safety definition

[Fergus Henderson <fjh@xxxxxxxxxxx>]

On 09-Jan-2004, David Abrahams <dave@xxxxxxxxxxxxxxxxxxxx> wrote:
> Dave Butenhof <David.Butenhof@xxxxxx> writes:
> 
> > Lessee here, Nathan's model I
> > believe could be trivially characterized as "return failure status on
> > any cancellation point until you hit a C++ function allowed to
> > throw". This would apparently disable any cleanup operations involving
> > cancellation points (they'd fail) at least prior to the first throw
> > point -- and it's not precisely clear how the "pending cancel" state
> > is to be managed even beyond that point. While it might eventually
> > lead to cancellation, it won't reliably perform cleanup. 
> 
> I'm having trouble understanding.  How does a "pending cancel state"
> perform cleanup?  And what do "reliably" and "cleanup" mean to you?

I think "it" in the last sentence quote above refers to Nathan's model,
not to the pending cancel state.

The problem is that cleanup -- e.g. execution of C++ destructors on
stack unwinding -- may involve calls to I/O routines that are themselves
cancellation points.  If these routines fail, then the cleanup functions
will not achieve their intended purpose; they will not be able to release
the resources that the thread holds.  Nathan's model implies that they
will fail.

> > It doesn't matter. There are many problems lurking here, and only one
> > of the more obvious is that this attempt to avoid breaking C code that
> > depends on 'if (error) {cleanup(); return error;}' will still break if
> > 'cleanup()' depends on any cancellation points... which in fact is
> > quite likely if 'error' originates from a cancellation point (e.g.,
> > I/O). 
> 
> In what sense will it break?

In this example, the function "cleanup()" may need to do I/O to
properly release the resources that the thread holds, but this
I/O will fail.

> > (It might actually be
> > better if the pending cancel wasn't "sticky", 
> 
> You lost me.  What's "sticky"?

When a thread gets a cancellation request, the first
cancellation point encountered thereafter will act on that request
(by unwinding the stack, or in Nathan's model by returning an error
return status and setting errno = ECANCELLED).  If another
cancellation point is encountered after that, and there has not
been another cancellation request, then the cancellation point
will normally not have any effect.

With "sticky" cancels, after a cancellation request,
*every* subsequent cancellation point will act on the cancel
(by unwinding the stack, or failing with ECANCELLED).

"stick" cancels make it difficult/impossible to clean up properly,
since cleaning up may involve doing I/O, and in particular by calling
functions that Posix specifies are cancellation points.  These functions
will fail to do the I/O, because they will instead attempt to act on
the cancellation again (i.e. re-raising the cancellation exception
or failing with ECANCELLED).

-- 
Fergus Henderson <fjh@xxxxxxxxxxx>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.