JavaMemoryModel: What Causality test cases does the CLI/C# memory model allow?

From: Bill Pugh (pugh@cs.umd.edu)
Date: Tue Mar 30 2004 - 14:04:07 EST


[Please forward to anyone who might be better able to answer
CLI/C# questions]

Now that we are coming down to the wire on the Java memory model,
it is a good time to go back and compare it to the C#/CLI
memory model. In looking at the CLI spec, we find that we can't
figure out how to interpret whether some particular
test cases are allowed or not.

Over the past year one of the most difficult issues
we've faced has been trying to handle the notation of causality
in the memory model, so that we disallow cases in which an
event causes itself. In particular, we don't want to allow
correctly synchronized programs to exhibit data races arising
from a causal loop.

We've distilled many of these issues down into the Causality Test
Cases:
        http://www.cs.umd.edu/~pugh/java/memoryModel/CausalityTestCases.html

I think the ones of most interest are test cases 3, 4, 5, 9, 13, 14 and
18.
Test cases 4, 13 and 14 are correctly synchronized. Of these, the Java
memory model
doesn't allow the behaviors shown in test cases 4, 5, 13 and 14.

Jeremy and I have looked through the ECMA CLI spec, and have been
unable to
tell whether the CLI spec either allows or forbids the behaviors in
question.
Clearly, having a CLI spec that doesn't tell you whether a particular
behavior is allowed or not isn't a good thing.

The relevant CLI spec is section 12.6 of partition I of the CLI spec,
available
at:
        http://www.ecma-international.org/publications/standards/Ecma-335.htm

The most relevant part seems to be:
> 12.6.4 Optimization
> Conforming implementations of the CLI are free to execute programs
> using any technology that guarantees,
> within a single thread of execution, that side-effects and exceptions
> generated by a thread are visible in the
> order specified by the CIL. For this purpose volatile operations
> (including volatile reads) constitute side-effects.
> Volatile operations are specified in clause 12.6.7. There are no
> ordering guarantees relative to
> exceptions injected into a thread by another thread (such exceptions
> are sometimes called “asynchronous
> exceptions,” e.g., System.Threading.ThreadAbortException).
> Rationale: An optimizing compiler is free to reorder side-effects and
> synchronous exceptions to the extent that
> this reordering does not change any observable program behavior.
> Note: An implementation of the CLI is permitted to use an optimizing
> compiler, for example, to convert CIL to
> native machine code provided the compiler maintains (within each
> single thread of execution) the same order
> of side-effects and synchronous exceptions.
> This is a stronger condition than ISO C++ (which permits reordering
> between a pair of sequence points) or ISO
> Scheme (which permits reordering of arguments to functions).

We would be grateful if anyone could try to explain how to interpret
the CLI semantics
on these test cases: whether the behaviors in test cases 3, 4, 5, 9,
13, 14 and 18 are
allowed, and how to derive that from the specification.

Bill Pugh

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:02 EDT