[m-rev.] for review: bug fixes for threads

Julien Fischer juliensf at csse.unimelb.edu.au
Tue Feb 20 18:38:43 AEDT 2007


On Tue, 20 Feb 2007, Peter Wang wrote:

> Some bug fixes to do with threads.
>
> library/io.m:
> 	ML_maybe_make_err_msg() was not thread-safe but was called from some
> 	`thread_safe' foreign_procs.  Make ML_maybe_make_err_msg() acquire the
> 	global lock if the caller does not acquire the global lock itself.
>
> library/thread.m:
> runtime/mercury_thread.c:
> 	Create threads in the detached state so that resources will be
> 	automatically freed when threads terminate (we don't call
> 	pthread_join() anywhere).
>
> library/thread.semaphore.m:
> 	Wake up waiting threads in FIFO order, instead of LIFO order.
>
> runtime/mercury_context.c:
> runtime/mercury_context.h:
> runtime/mercury_engine.c:
> runtime/mercury_engine.h:
> 	Change the way we enforce that a Mercury context returning from Mercury
> 	code back into a C function runs on the original Mercury engine that
> 	called the C function.
>
> 	Previously, if a C function called into Mercury code, the Mercury
> 	context would be "owned" by that Mercury engine until the C function
> 	finished.  If the Mercury code suspended (e.g. waiting on a semaphore),
> 	it could not be resumed by another Mercury engine.  This was
> 	unnecessarily conservative.
>
> 	Now any Mercury engine can resume a suspended context.  Just before
> 	returning into C functions, we check that the context is actually
> 	running on the Mercury engine in which the C function was started.  If
> 	not, *then* we reschedule the context so that it will only be picked up
> 	by the right Mercury engine.
>
> 	Add a comment that none of this is implemented for grades not using gcc
> 	non-local gotos (nor was it implemented before).

Out of curiosity is there some particular difficulty in implementing it
in the absence of non-local gotos?

> runtime/mercury_memory_zones.c:
> 	Fix an off-by-one bug and a thread-safety bug in MR_next_offset().

...

> Index: runtime/mercury_engine.c
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/runtime/mercury_engine.c,v
> retrieving revision 1.55
> diff -u -r1.55 mercury_engine.c
> --- runtime/mercury_engine.c	11 Dec 2006 03:03:13 -0000	1.55
> +++ runtime/mercury_engine.c	16 Feb 2007 04:07:40 -0000
> @@ -37,6 +37,7 @@
>
>   #ifndef MR_USE_GCC_NONLOCAL_GOTOS
>     static MR_Code  *engine_done(void);
> +    static MR_Code  *engine_done_2(void);
>     static MR_Code  *engine_init_registers(void);
>   #endif

I don't understand the distinction between engine_done and
engine_done_2.

...

> Index: runtime/mercury_thread.c
> ===================================================================
> RCS file: /home/mercury1/repository/mercury/runtime/mercury_thread.c,v
> retrieving revision 1.30
> diff -u -r1.30 mercury_thread.c
> --- runtime/mercury_thread.c	16 Jan 2007 23:45:05 -0000	1.30
> +++ runtime/mercury_thread.c	15 Feb 2007 10:37:37 -0000
> @@ -49,7 +49,9 @@
>
>     thread = MR_GC_NEW(MercuryThread);
>     pthread_attr_init(&attrs);
> +    pthread_attr_setdetachstate(&attrs, PTHREAD_CREATE_DETACHED);

It's probably worth adding a comment about why it is okay to create
detached threads here (e.g. essentially what was in the log message for
this file.)

>     err = pthread_create(thread, &attrs, MR_create_thread_2, (void *) goal);
> +    pthread_attr_destroy(&attrs);

The rest looks okay.

Julien.


--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list