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
Leghorn)
> 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
general.
>
> 1) Thread cancelation comes in three flavors: immediate, deferred,
and
> ignored. Immediate means one thread cancels another and the other
immediately
> exits. Deferred means the other doesn't exit until it hits a
cancelation
> point. Ignored means cancelation is not possible(honored). Boost is
ignored
> 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
bizarre
> implementation of pthead_cancel_push() and pthread_cancel_pop())
>
> 5) Thread cancellation is NOT an exception. Period. It is an event
to
> be handled. In fact I believe Xavier Leroy implemented
thread_cancelation
> 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
simple
> rules to keep everything cancel safe. I think policy based
programming would
> really help here as Andrei shows it helps concurrent in general. Of
course
> 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