[m-rev.] For review: Improvments to Stack Segments code.
pbone at csse.unimelb.edu.au
Tue Apr 5 19:26:09 AEST 2011
On Tue, Apr 05, 2011 at 06:54:03PM +1000, Julien Fischer wrote:
> On Tue, 5 Apr 2011, Paul Bone wrote:
> >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
> >>>>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.
> In which grade is the foreign code not annotated with a thread_safe
> attrbute? (For hlc.gc.trseg.par both the library trail ops, in
> library/private_builtin.m, and the inline versions, in
> compiler/add_trail_ops.m, do appear to be annotated with thread_safe
set_max_attr_2 and friends in fd.rep.m in g12/solvers/fd
My fix worked.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: Digital signature
More information about the reviews