Re: Boost.Threads - name of the "thread" type

From: williamkempf_at_[hidden]
Date: 2001-06-22 12:23:09

--- In boost_at_y..., John Max Skaller <skaller_at_o...> wrote:
> williamkempf_at_h... wrote:
> 
> > Actually, I have no plans at this time to support thread 
cancellation
> > (to use terminology more familiar to most folks here).  Thread
> > cancellation is a slippery slope in C++ for reasons beyond just 
those
> > discovered in Java.
> 
> 	If you don't, people will have to roll their own.

Which is a safer approach.  Seriously.  This may sound backwards, but 
there's enough existing evidence to support this.  Even Java has 
eliminated thread cancellation from their libraries.

Some of the issues:

1)  Cancellation usually doesn't address lifetime issues completely 
or appropriately.  For instance, pthread cancellation and Win thread 
cancellation when used in the C++ language fails to properly call 
destructors.  On Win threads mutexes that are locked when a thread is 
cancelled become "abandoned", which can lead to race errors or other 
problems (I don't know how pthreads deals with this).

2)  Cancellation can lead to deadlock or race conditions if the 
synchronization options aren't very carefully used (such as the 
abandoned mutexes from 1).

3)  Cancellation can cause critical operations to be abandoned only 
partially completed.  If cancellation can only occur at 
specific "cancellation points" then it's possible to manage this 
issue, but doing so is complex and is rarely if ever done, though the 
existence of cancellation means it should always be done (think of 
the complexities of exception handling but at a grander scale).

The only slightly viable library solution I've seen to this was 
having the cancellation points throw a specific exception if a thread 
has been cancelled.  This exception would then be caught by the 
master thread proc (an implementation detail hidden from programmers) 
which would simply return, thus exiting the thread cleanly.  The 
problem with this is that catch(...) statements can wreak havoc with 
the intended behavior, reducing this design to uselessnes in 
generalized code (i.e. you have to code your thread very carefully to 
not make this mistake).

A language solution instead of a library solution can eliminate most, 
but not all of these problems.  Again, look at Java for proof of this.

Explicit user cancellation coded with condition variables are trivial 
to implement, and are fully safe, however.  So there's not a real 
need for library support of cancellation, while the dangers in 
providing library support a great.

Bill Kempf