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

[Paul Bone]

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
> >>>>>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.
> 
> 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
> attributes.)

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...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20110405/20a9aa13/attachment.sig>