how to kill native code threads?

how to kill native code threads?

[Markus Mottl]

Hello,

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 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?

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: how to kill native code threads?

[John Max Skaller]

Markus Mottl wrote:
> 
> Hello,
> 
> 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?

	[This information from a coworker who is expert in threads,
which I am not]

	You can't. There IS supposedly a way to do this in general, 
using Posix thread cancellation. It isn't clear that this will work
correctly
with Ocaml, however, and for this reason it isn't part of the 
threads library. [It also only works on Posix systems].

	Where I work, there is a different problem:
code is written in C++, and when a thread is cancelled,
it is necessary to unwind the stack to execute destructors.
Linux does not do this. I'm told Solaris tries.

	Posix requires certain functions check for cancellation.
Unfortunately, there is a bug in the Posix specification,
such that NOT all blocking calls perform the requisite check.
This means Posix thread cancellation doesn't work properly
in all cases. I can't remember the offending calls off hand,
[connect?] but you need to add a manual check and use a non-blocking
call
in that case.

	Executive summary: there's no simple solution, not even in C.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: how to kill native code threads?

[Xavier Leroy]

> 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