Re: how to kill native code threads?

From: Xavier Leroy (Xavier.Leroy@inria.fr)
Date: Tue May 09 2000 - 10:52:57 MET DST

  • Next message: John Max Skaller: "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



    This archive was generated by hypermail 2b29 : Thu May 11 2000 - 14:58:09 MET DST