I expect you will need someone from Microsoft to explain the .NET memory
model.
I will point out the article by Vance Morrison cited below is more than
a year and a half old and in my personal opinion
contains some fairly clear errors. (You really
don't want writes to be able to move before a lock acquisition any more
than reads. In the standard, volatiles do constrain ordering. The LazyInit
example ignores the issue of reordering on the read side, which seems
to be a common problem.)
There is some more discussion of the .NET memory model at
http://blogs.msdn.com/cbrumme/archive/2003/05/17/51445.aspx
I participated in that discussion, but I don't think I can
summarize an outcome.
Hans
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Joseph Bowbeer
> Sent: Tuesday, March 30, 2004 12:35 PM
> To: javamemorymodel-cs.umd.edu; Bill Pugh
> Subject: Re: JavaMemoryModel: What Causality test cases does
> the CLI/C#
> memory model allow?
>
>
> 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
-------------------------------
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