Fyi -
I recall reading something about a MemoryBarrier API in .Net, and found some
mention here:
http://discuss.develop.com/archives/wa.exe?A2=ind0203B&L=DOTNET&P=R375&I=-3
A DCL LazyInit class is used for illustration...
-----
The DOTNET framework does however, define APIs that allow you to fix the
problem
System.Threading.Thread.WriteMemoryBarrier()
System.Threading.Thread.MemoryBarrier()
Which have the following properties.
1) Writes can not cross a System.Threading.Thread .WriteMemoryBarrier()
(This is often much cheaper than a full memory barrier)
2) Neither reads nor writes can cross a
System.Threading.Thread.MemoryBarrier().
-----
----- Original Message -----
From: "Bill Pugh" <pugh@cs.umd.edu>
To: "javamemorymodel-cs.umd.edu" <javamemorymodel@cs.umd.edu>
Sent: Tuesday, March 30, 2004 11:04 AM
Subject: JavaMemoryModel: What Causality test cases does the CLI/C# memory
model allow?
[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