Skip to content

Commit f5dec36

Browse files
authored
Fix minor typo/formatting in the memory model spec (#128817)
.Net → .NET
1 parent 6963a59 commit f5dec36

1 file changed

Lines changed: 1 addition & 1 deletion

File tree

docs/design/specs/Memory-model.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -105,7 +105,7 @@ It may be possible for an optimizing compiler to prove that some data is accessi
105105
- `System.Threading.Interlocked` methods
106106

107107
## C# `volatile` feature
108-
One common way to introduce volatile memory accesses is by using C# `volatile` language feature. Declaring a field as `volatile` does not have any effect on how .NET runtime treats the field. The decoration works as a hint to the C# compiler itself (and compilers for other .Net languages) to emit reads and writes of such field as reads and writes with `volatile.` prefix.
108+
One common way to introduce volatile memory accesses is by using C# `volatile` language feature. Declaring a field as `volatile` does not have any effect on how .NET runtime treats the field. The decoration works as a hint to the C# compiler itself (and compilers for other .NET languages) to emit reads and writes of such field as reads and writes with `volatile.` prefix.
109109

110110
## Process-wide barrier
111111
Process-wide barrier has full-fence semantics with an additional guarantee that each thread in the program effectively performs a full fence at arbitrary point synchronized with the process-wide barrier in such a way that effects of writes that precede both barriers are observable by memory operations that follow the barriers.

0 commit comments

Comments
 (0)