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

[Fergus Henderson]

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.

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.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "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.