Boost logo

Boost :

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-15 12:05:40

--- In boost_at_y..., Lee Brown <lee_at_a...> wrote:
> Thank you all, this "thread" ("Hey! I made that funny" a la Foghorn
> has been very insightful to me.
> These are things as I see them. I know nothing of Windows.
> I am quite conversant with Posix threads and thread issues in
> 1) Thread cancelation comes in three flavors: immediate, deferred,
> ignored. Immediate means one thread cancels another and the other
> exits. Deferred means the other doesn't exit until it hits a
> point. Ignored means cancelation is not possible(honored). Boost is
> mode capable only.

I know these modes under the names asynchronous, cooperative and
disabled, but these are the three modes we've discussed in
this "thread" (to borrow your funny). Today Boost.Threads supports
only ignored/disabled (a unique way to look at it... I'd prefer to
say it simply doesn't support cancellation). However, there are
plans to support cooperative/deferred as well.

> 2) Immediate cancelation is not possible without a thread being
able to put
> itself into defer or ignore state and back again.
> 3) Cancelation is not possible without a resource cleanup stack.

More importantly, this "stack" must be the traditional C++ stack,
insuring that all destructors are called.
> 4) If cancelation is in effect, resources should be aquired and
released in
> the same scope and in reverse order.(FYI: I believe reverse order
is the only
> important fact, same scope merely ensures this. This is the
> implementation of pthead_cancel_push() and pthread_cancel_pop())
> 5) Thread cancellation is NOT an exception. Period. It is an event
> be handled. In fact I believe Xavier Leroy implemented
> through a signal handler. Thread cancelation was merely a special
case of
> sending a signal to a thread.

Cancellation *IS* a form of an exception. Or to be put another way,
the behavior of cancellation must be identical to the behavior of an
exception being thrown (possibly barring the ability for a user to
catch the "exception"). In other words, it must unwind the stack in
the same manner that an exception does. Any other implementation in
C++ is unusable. This is one of the pains of using POSIX in a C++
program today.
> 6) Actually, these mailings have reinforced my opinion that
cancelation would
> be quite safe and easy to implement in C++ (at least in UNIX), with
> rules to keep everything cancel safe. I think policy based
programming would
> really help here as Andrei shows it helps concurrent in general. Of
> its hard to know until it is done because multithreaded stuff can
be subtle.
> i.e.
> thread_routine()
> {
> cancel_safe_lock l(mutex_);
> smart_ptr<Object> o =
> CreatePolicy<Object,cancel_safe_thread_policy>create();
> }
> Then again maybe I'm an idiot.

Cooperative/deferred cancelation most certainly can be done safely
and effectively in C++. Doing so portably puts a few constraints on
us. For instance, Boost.Threads is going to have to use an actual
C++ exception here (I believe), while the standard could just use
a "kissing cousin" to the exception (i.e. the standard could make the
type non-catchable).

Asynchronous/immediate cancellation, on the other hand, poses several
more issues. It's highly dangerous to use in C++ (actually, in any
language, IMHO), but it can provide an optimization in certain cases,
so may be desired despite the dangers.

Bill Kempf

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