The CLI/C# spec is done, and is available from:
http://www.ecma.ch/ecma1/STAND/ecma-334.htm (C# spec)
http://www.ecma.ch/ecma1/STAND/ecma-335.htm (CLI spec)
http://www.ecma.ch/ecma1/techrep/e-tr-084.htm (CLI libraries?)
The CLI memory model is described on pages 92-95 of partition I of
the CLI spec.
Very briefly, by design the CLI spec does not allow the removal of
synchronization/coherence actions associated with thread local
volatiles or monitors. This makes the design much simpler, and I had
hoped that they might come up with something halfway decent, given
their design choice.
They designed to ignore much of the advice I gave them. In the
official ECMA spec:
* Word tearing is defined to occur. If threads write adjacent bytes
without synchronization, it is a data race and one of the writes may
be lost.
* volatile read/writes of a 64-bit value on a 32-bit processor are _not_
atomic, unless you perform the volatile read/write using a call to methods
such as Thread.VolatileWrite
Plus, the spec is ambiguous in the extreme and has holes you could
drive a truck through.
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:36 EDT