[m-rev.] For review: Improvments to Stack Segments code.

Paul Bone pbone at csse.unimelb.edu.au
Tue Apr 5 16:11:13 AEST 2011

On Tue, Apr 05, 2011 at 01:41:24AM +1000, Julien Fischer wrote:
> On Mon, 4 Apr 2011, Paul Bone wrote:
> >On Fri, Feb 25, 2011 at 03:38:45PM +1100, Julien Fischer wrote:
> >>On Fri, 25 Feb 2011, Julien Fischer wrote:
> >>>hlc.par.gc.trseg is is broken, the `bounds_inconsistent' test
> >>>with parameter 10000000, appears to go into a loop (possibly it
> >>>deadlocks?)
> >>
> >>Same thing for asm_fast.par.gc.trseg.
> >
> >Is this a G12 test?
> Yes, it's part of the G12's FD solver benchmarks.
> (MarkB or Sebastian should be able to point you in direction of
> that particular test case; fortunately it's relatively self-contained.)

Okay I think I've found the problem.

Foreign C code is used to create trail entries, that code is not annotated with
the thread_safe attribute.  A trail entry that would cause the trail to expand
and a new trail segment to be allocated uses Mercury's global lock to determine
the offset for that trail.  This lock has already been aquired by the current
thread and is no reenterant.  The thread is deadlocked.  This may have been a
problem before I modified the memory zones code.

I've replaced the use of the global lock with a CAS loop, I'm testing it now.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20110405/c9f2ebda/attachment.sig>

More information about the reviews mailing list