[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