Boost logo

Boost :

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
> > (to use terminology more familiar to most folks here). Thread
> > cancellation is a slippery slope in C++ for reasons beyond just
> > 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at