[m-dev.] Concurrency stuff status?

Fergus Henderson fjh at cs.mu.OZ.AU
Sat Nov 18 12:23:03 AEDT 2000


On 17-Nov-2000, Ralph Becket <rbeck at microsoft.com> wrote:
> I'm doing some performance tests of various search algorithms.
> On some problems, solver A will work in seconds while solver B
> is still going the next day.  I'd like to do something like
> this: have one thread performing the computation and another
> thread that just sleeps for an hour, say, and then kills the
> worker thread if it's still going.
> 
> This requires both preemptive scheduling (the README in
> extras/concurrency only mentions coroutining)

The documentation of the concurrency stuff is a bit out of date.
Grades asm_fast.gc.par (with MERCURY_OPTIONS="-P <numthreads>") and
hlc.gc.par both give you concurrency.  (One of those two grades --
I think it was asm_fast.gc.par -- is currently broken on the x86 for
reasons that we don't understand.)

But if you just want timeouts, it may be better to use alarm()
and signals rather than multithreading.

> and some way of killing threads from the `outside'.

That is going to be difficult.  It's hard to ensure that you don't
kill the thread at some inopportune moment, such as while it is
holding the allocation lock and has left the heap in an inconsistent
state.

An simpler approach is to have the thread regularly poll some indicator
(e.g. a per-thread variable of type `volatile sig_atomic_t') that
tells it when to quit.  You can set this indicator in the other thread
or in the signal handler.  (For the hlc.gc.par grade, you could
use pthread_cancel() and pthread_testcancel().)

I suppose it would be nice if the Mercury compiler optionally generated
such checks automatically at the start of the code for each procedure,
throwing an exception if the indicator is set.  (This has to be
optional because it will probably be very bad for performance.)
But programming code that is safe against asynchronous exceptions is
quite tricky.  You'd need to be very careful to disable async
exceptions whenever the global state is inconsistent.  You also need
to be careful to ensure that any locks or other resources which are
held when an async exception is received get properly released.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list