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

[Julien Fischer]

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

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
--------------------------------------------------------------------------