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 only volatile operations (including volatile reads) constitute visible side-effects. (Note that while only volatile operations constitute visible side-effects, volatile operations also affect the visibility of non-volatile references.) Volatile operations are specified in §I.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. end rationale]
[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). end note]
Optimizers are granted additional latitude for relaxed exceptions in methods. A method is E-relaxed for a kind of exception if the innermost custom attribute System.Runtime.CompilerServices. CompilationRelaxationsAttribute pertaining to exceptions of kind E is present and specifies to relax exceptions of kind E. (Here, "innermost" means inspecting the method, its class, and its assembly, in that order.)
A E-relaxed sequence is a sequence of instructions executed by a thread, where
-
Each instruction causing visible side effects or exceptions is in an E-relaxed method.
-
The sequence does not cross the boundary of a non-trivial protected or handler region. A region is trivial if it can be optimized away under the rules for non-relaxed methods.
Below, an E-check is defined as a test performed by a CIL instruction that upon failure causes an exception of kind E to be thrown. Furthermore, the type and range tests performed by the methods that set or get an array element's value, or that get an array element's address are considered checks here.
A conforming implementation of the CLI is free to change the timing of relaxed E-checks in an E-relaxed sequence, with respect to other checks and instructions as long as the observable behavior of the program is changed only in the case that a relaxed E-check fails. If an E-check fails in an E-relaxed sequence:
-
The rest of the associated instruction must be suppressed, in order to preserve verifiability. If the instruction was expected to push a value on the VES stack, no subsequent instruction that uses that value should visibly execute.
-
It is unspecified whether or not any or all of the side effects in the E-relaxed sequence are made visible by the VES.
-
The check's exception is thrown some time in the sequence, unless the sequence throws another exception. When multiple relaxed checks fail, it is unspecified as to which exception is thrown by the VES.
[Note: Relaxed checks preserve verifiability, but not necessarily security. Because a relaxed check’s exception might be deferred and subsequent code allowed to execute, programmers should never rely on implicit checks to preserve security, but instead use explicit checks and throws when security is an issue. end note]
[Rationale: Different programmers have different goals. For some, trading away precise exception behavior is unacceptable. For others, optimization is more important. The programmer must specify their preference. Different kinds of exceptions may be relaxed or not relaxed separately because different programmers have different notions of which kinds of exceptions must be timed precisely. end rationale]
[Note: For background and implementation information for relaxed exception handling, plus examples, see Annex F of Partition VI. end note]