Version française
Home     About     Download     Resources     Contact us    
Browse thread
how to kill native code threads?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: how to kill native code threads?
> The documentation of the "Thread.kill" function says that it only works for
> bytecode-level threads.
> But how can I terminate native threads from outside? Say, for example, I
> want to run some state space search on several processors and create native
> threads that search a specific part of the search space.

In general, killing threads at any point in their execution is unsafe,
because the thread can die while holding critical resources,
e.g. mutexes, and this will prevent other threads from running
correctly.

Thread.kill in the bytecode thread library is actually an historical
error.  It wasn't implemented in the native thread library because the
underlying system threads (POSIX or Win32) explicitly discourage
asynchronous thread cancellation.  Thread.kill should have been
removed from bytecode threads as well.

(Similar things happen in Java: the original Java implementation
supported thread termination at any time, but Java 2 deprecates this
and proposes another mechanism.)

> In the moment one returns with the solution I don't want the others
> continue running. One could stop them by sending them some kind of stop
> event, but the threads would have to check for this event at regular times,
> which is unelegant to program and costs time: if the thread checks too
> often, it will lose performance on the search; if it does so too seldom, we
> might have a considerable delay until it reacts to the termination event.
> 
> Is there another (safe) way to do it?

Polling is always safe, if a bit inelegant.  That's the solution that
POSIX threads, Modula-3 and (I think) Java 2 encourage, with a bit
of systems support to avoid problems with blocking operations.

In the case of POSIX, for instance, a thread can post a "cancellation
request" for another thread.  By default, the target thread honors the
cancellation request only when it tests explicitly for pending
cancellation, or when it performs a potentially blocking operation
(such as I/O or waiting on a condition variable).

The default effect of cancellation is to terminate the thread, but
user-provided functions can be called at cancellation time to
e.g. release mutexes.  In ML, this maps nicely to raising an exception
in the target thread, which can then be caught to release mutexes and
so on.

Cancellation never occurs while waiting for a mutex, so that the state
of a mutex is always predictable, even inside cancellation cleanup
code.

Then, there is the option of allowing immediate cancellation in pieces
of long-running code that don't hold any resources.

A recent paper by Marlow, Peyton-Jones and Moran
(http://research.microsoft.com/Users/simonpj/papers/asynch-exns.ps.gz)
proposes a symmetric approach: cancellation is immediate by default,
but can be deferred over critical pieces of code using scoped
"block" and "unblock" combinators.

The POSIX model (or Peyton-Jones' variant) is a strong candidate for
inclusion in the Caml threads libraries.  Unfortunately, Win32 system
threads do not provide adequate support for this model, so I'm not
sure this can be made to work under Win32.

- Xavier Leroy