view tests-custom/src/main/resources/org/openjdk/jcstress/desc/fences.xml @ 66:d7f7a93800e4

Rewire the grading levels: introduce ACCEPTABLE_SPEC, remove REQUIRED, renames.
author shade
date Thu, 28 Nov 2013 19:10:32 +0400
parents dd797d922f1c
children 7a9f5f818d94
line wrap: on
line source
<!--

    Copyright (c) 2005, 2013, Oracle and/or its affiliates. All rights reserved.
    DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

    This code is free software; you can redistribute it and/or modify it
    under the terms of the GNU General Public License version 2 only, as
    published by the Free Software Foundation.  Oracle designates this
    particular file as subject to the "Classpath" exception as provided
    by Oracle in the LICENSE file that accompanied this code.

    This code is distributed in the hope that it will be useful, but WITHOUT
    ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
    FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
    version 2 for more details (a copy is included in the LICENSE file that
    accompanied this code).

    You should have received a copy of the GNU General Public License version
    2 along with this work; if not, write to the Free Software Foundation,
    Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

    Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
    or visit www.oracle.com if you need additional information or have any
    questions.

-->
<testsuite>

    <test name="org.openjdk.jcstress.tests.fences.UnfencedReadTwiceTest">
        <contributed-by>Aleksey Shipilev (aleksey.shipilev@oracle.com)</contributed-by>
        <description>
            Tests if intervening writes break the ordering.
        </description>
        <case>
            <match>[0, 0, 0]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Default value for the fields. Observers are allowed to see the default value for the field,
                because there is the data race between reader and writer.
            </description>
        </case>
        <case>
            <match>[0, 1, 0]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                The evidence for the correct reordering: the later write is seen first.
            </description>
        </case>
        <case>
            <match>[1, 0, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Write to $y is still in flight, $x is already here.
            </description>
        </case>
        <case>
            <match>[0, 0, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Write to $y is still in flight, $x is arriving late.
                This is the evidence the compiler had not merged the loads for $x.
            </description>
        </case>
        <case>
            <match>[0, 1, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                The writes appear the the writers' order.
                This code also means the compiler had not merged the loads for $x.
            </description>
        </case>
        <case>
            <match>[1, 0, 0]</match>
            <match>[1, 1, 0]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                TODO: Odd, but legal case?
            </description>
        </case>
        <case>
            <match>[1, 1, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Both updates are visible.
            </description>
        </case>
        <unmatched>
            <expect>FORBIDDEN</expect>
            <description>
                This case is not expected.
            </description>
        </unmatched>
    </test>

    <test name="org.openjdk.jcstress.tests.fences.FencedDekkerTest">
        <contributed-by>Doug Lea (dl@cs.oswego.edu)</contributed-by>
        <description>
            Tests the sequential consistency on Dekker-like construction using explicit fences, not volatiles
        </description>
        <case>
            <match>[0, 1]</match>
            <match>[1, 0]</match>
            <match>[1, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Acceptable under sequential consistency
            </description>
        </case>
        <case>
            <match>[0, 0]</match>
            <expect>FORBIDDEN</expect>
            <description>
                Un-acceptable under sequential consistency
            </description>
        </case>
        <unmatched>
            <expect>FORBIDDEN</expect>
            <description>
                Other cases are not expected.
            </description>
        </unmatched>
    </test>

    <test name="org.openjdk.jcstress.tests.fences.UnfencedDekkerTest">
        <contributed-by>Doug Lea (dl@cs.oswego.edu)</contributed-by>
        <description>
            Baseline comparison to FencedDekkerTest
        </description>
        <case>
            <match>[0, 1]</match>
            <match>[1, 0]</match>
            <match>[1, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Acceptable even within sequential consistency.
            </description>
        </case>
        <case>
            <match>[0, 0]</match>
            <expect>ACCEPTABLE_INTERESTING</expect>
            <description>
                Acceptable without sequential consistency enforced.
            </description>
        </case>
        <unmatched>
            <expect>FORBIDDEN</expect>
            <description>
                Other cases are not expected.
            </description>
        </unmatched>
    </test>

    <test name="org.openjdk.jcstress.tests.fences.FencedAcquireReleaseTest">
        <contributed-by>Doug Lea (dl@cs.oswego.edu)</contributed-by>
        <description>
            Test if releasing write induces ordering of corresponding acquiring read.
        </description>
        <case>
            <match>[0, 0]</match>
            <match>[0, 1]</match>
            <match>[0, 2]</match>
            <match>[0, 3]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Before obeserving releasing write to, any value is OK for $x.
            </description>
        </case>
        <case>
            <match>[1, 0]</match>
            <match>[1, 1]</match>
            <expect>FORBIDDEN</expect>
            <description>
                Can't read the default or old value for $x after $y is observed.
            </description>
        </case>
        <case>
            <match>[1, 2]</match>
            <match>[1, 3]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Can see a released value of $x if $y is observed.
            </description>
        </case>
        <unmatched>
            <expect>FORBIDDEN</expect>
            <description>
                This case is not expected.
            </description>
        </unmatched>
    </test>

    <test name="org.openjdk.jcstress.tests.volatiles.VolatileAcquireReleaseTest">
        <contributed-by>Doug Lea (dl@cs.oswego.edu)</contributed-by>
        <description>
            Test if releasing volatile write induces ordering of corresponding acquiring read.
        </description>
        <case>
            <match>[0, 0]</match>
            <match>[0, 1]</match>
            <match>[0, 2]</match>
            <match>[0, 3]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Before obeserving releasing write to, any value is OK for $x.
            </description>
        </case>
        <case>
            <match>[1, 0]</match>
            <match>[1, 1]</match>
            <expect>FORBIDDEN</expect>
            <description>
                Can't read the default or old value for $x after $y is observed.
            </description>
        </case>
        <case>
            <match>[1, 2]</match>
            <match>[1, 3]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Can see a released value of $x if $y is observed.
            </description>
        </case>
        <unmatched>
            <expect>FORBIDDEN</expect>
            <description>
                This case is not expected.
            </description>
        </unmatched>
    </test>

    <test name="org.openjdk.jcstress.tests.fences.UnfencedAcquireReleaseTest">
        <contributed-by>Doug Lea (dl@cs.oswego.edu)</contributed-by>
        <description>
            Baseline unfenced version of FencedAcquireReleaseTest
        </description>
        <case>
            <match>[0, 0]</match>
            <match>[0, 1]</match>
            <match>[0, 2]</match>
            <match>[0, 3]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Before observing releasing write to, any value is OK for $x.
            </description>
        </case>
        <case>
            <match>[1, 0]</match>
            <match>[1, 1]</match>
            <expect>ACCEPTABLE_INTERESTING</expect>
            <description>
                Without fence or volatile can read the default or old value for $x after $y is observed.
            </description>
        </case>
        <case>
            <match>[1, 2]</match>
            <match>[1, 3]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Can see a released value of $x if $y is observed.
            </description>
        </case>
        <unmatched>
            <expect>FORBIDDEN</expect>
            <description>
                This case is not expected.
            </description>
        </unmatched>
    </test>

    <test name="org.openjdk.jcstress.tests.fences.FencedPublicationTest">
        <contributed-by>Doug Lea (dl@cs.oswego.edu)</contributed-by>
        <description>
            Tests use of fenced writes to fields before publication
        </description>
        <case>
            <match>[0, 0]</match>
            <match>[0, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Data not yet published.
            </description>
        </case>
        <case>
            <match>[1, 0]</match>
            <expect>FORBIDDEN</expect>
            <description>
                Can't read the default value for field $x after publication.
            </description>
        </case>
        <case>
            <match>[1, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Must read the written value for $x after publication.
            </description>
        </case>
        <unmatched>
            <expect>FORBIDDEN</expect>
            <description>
                This case is not expected.
            </description>
        </unmatched>
    </test>

    <test name="org.openjdk.jcstress.tests.fences.UnfencedPublicationTest">
        <contributed-by>Doug Lea (dl@cs.oswego.edu)</contributed-by>
        <description>
            Baseline comparison for FencedPublicationTest
        </description>
        <case>
            <match>[0, 0]</match>
            <match>[0, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Data not yet published
            </description>
        </case>
        <case>
            <match>[1, 0]</match>
            <expect>ACCEPTABLE_INTERESTING</expect>
            <description>
                Reads the default value for field $x after publication.
            </description>
        </case>
        <case>
            <match>[1, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Must read the written value for $x after publication.
            </description>
        </case>
        <unmatched>
            <expect>FORBIDDEN</expect>
            <description>
                This case is not expected.
            </description>
        </unmatched>
    </test>

    <test name="org.openjdk.jcstress.tests.fences.FencedReadTwiceTest">
        <contributed-by>Doug Lea (dl@cs.oswego.edu)</contributed-by>
        <description>
            Test if acquire/release forces re-read
        </description>
        <case>
            <match>[0, 0, 0]</match>
            <match>[0, 0, 1]</match>
            <match>[0, 1, 1]</match>
            <match>[1, 0, 1]</match>
            <match>[1, 1, 1]</match>
            <expect>ACCEPTABLE</expect>
            <description>
                Consistent ordered reads.
            </description>
        </case>
        <case>
            <match>[1, 1, 0]</match>
            <match>[0, 1, 0]</match>
            <match>[1, 0, 0]</match>
            <expect>FORBIDDEN</expect>
            <description>
                Lost or reordered read of x.
            </description>
        </case>
        <unmatched>
            <expect>FORBIDDEN</expect>
            <description>
                This case is not expected.
            </description>
        </unmatched>
    </test>

</testsuite>