[c++-pthreads] What are the real issues?

[Nathan Myers]

On Wed, Jan 07, 2004 at 02:24:38PM +1100, Fergus Henderson wrote:
> On 06-Jan-2004, Nathan Myers <ncm at cantrip.org> wrote:
> > 
> > On Tue, Jan 06, 2004 at 11:33:47AM -0800, Matt Austern wrote:
> > > My feeling: it's just plain inevitable that a multithreaded program has 
> > > more functions that might throw than a single-thread program.  Dealing 
> > > with this is part of what it means to make a program thread-safe.  
> > 
> > This is far from clear, and makes a very poor starting assumption.  We 
> > have had thread-safe libraries for a long time.  Under one proposed 
> > model most can simply be declared already "cancellation-safe", without 
> > changes.
> 
> Thread-safe code which may perform unbounded computation without 
> encountering a cancellation-point is not what I would call 
> cancellation-safe.

I can't speak for what you would call cancellation-safe, but the 
POSIX C binding committee certainly calls libraries with that property 
cancellation-safe.

> So even if code has been written to be thread-safe, you need to
> analyze it in detail in order to be sure that it will be properly
> cancellation-safe.
>
> Perhaps we need to talk about two different kinds of cancellation
> safety; I'll call them "weakly cancellation safe" and "strongly
> cancellation safe".  For the former, you'd be guaranteed that it was
> OK to send a cancellation request to threads running such code, but
> the cancellation request might be delayed indefinitely or ignored.
> For the latter, you'd be guaranteed that it was OK to send a
> cancellation request, and in addition there would be a guarantee that
> the cancellation request would be acted on in a finite amount of time,
> i.e. that the cancelled thread would actually terminate.  (Suggestions
> on terminology welcome.  Are there existing terms for these notions?)
> 
> Using this terminology, my point above is that thread safety does not
> imply strong cancellation safety.

It seems the POSIX people (wisely) gave up on defining any concept of 
your strong-cancellation-safety.  Consider that in C code, even 
ensuring garden-variety cancellation safety is a hit-or-miss affair: 
cancellation handlers are subject to rot under the best circumstances.  

We have better prospects in C++, if we can, as it were, hitch the 
cancellation-safety wagon to the exception-safety horse.  Well-written 
exception handling code (i.e. implemented mainly in destructors) is 
much less subject to rot, being exercised on each block exit.  Many 
more people know how to write exception-safe C++ code than C 
cancellation-safe code.  (I'm not sure I would be able to write the 
latter, maintainably.  C simply lacks the tools for it.)

Nathan Myers
ncm at cantrip.org