[m-rev.] for review: Add barriers (for concurrency) to the standard library

[Paul Bone]

On Wed, Apr 09, 2014 at 02:08:23PM +0200, Sebastian Godelet wrote:
>
> On 08.04.2014 17:52, Julien Fischer wrote:
>>
>> Hi Paul,
>>
>> On Tue, 8 Apr 2014, Paul Bone wrote:
>>
>>> On Thu, Apr 03, 2014 at 05:10:04PM +1100, Paul Bone wrote:
>>>> For review by anyone
>>>
>>> Hi.
>>>
>>> This is waiting for a review, thanks.
>>
>> I'll take a look at it, but probably not until Thursday at the earliest.
> Hi,
>
> I've written (and attached) a simple test program to experiment with the  
> library,
> unfortunately I'm not sure how to integrate a new unit test in the compiler,
> but maybe you'd have a quick look and see the barrier code in action (to  
> safe some effort),
>

Thanks Sebastian,

Your testcase was very useful, it found a bug in the implementation of
barrier_release/3 (now called release/3).

Mercury developers:

Normally adding test cases is straightforward, and I would like to add
Sebastian's test case.  However this involves concurrency and so output may
not be printed in the same order on every execution.  Normally I might do
something like sort the lines of the output and compare that with a sorted
expected output, however this only works for C and Java based grades.  It
doesn't work for C# which (at least on mono on my Linux workstation) can ix
the output threads within the same line.  If any one has any ideas for this
kind of test I'd be interested.  Otherwise I think I'll create a directory
of tests for concurrency that sort their outputs and are disabled for C#.

Thanks.


-- 
Paul Bone