6

This question is a follow-up to comments in this thread.

Let's assume we have the following code:

// (1)
lock (padlock)
{
    // (2)
}
var value = nonVolatileField; // (3)

Furthermore, let's assume that no instruction in (2) has any effect on the nonVolatileField and vice versa.

Can the reading instruction (3) be reordered in such a way that in ends up before the lock statement (1) or inside it (2)?

As far as I can tell, nothing in the C# Specification (§3.10) and the CLI Specification (§I.12.6.5) prohibits such reordering.

Please note that this is not the same question as this one. Here I am asking specifically about read instructions, because as far as I understand, they are not considered side-effects and have weaker guarantees.

Community
  • 1
  • 1
tearvisus
  • 2,013
  • 2
  • 15
  • 32

2 Answers2

3

I believe this is partially guaranteed by the CLI spec, although it's not as clear as it might be. From I.12.6.5:

Acquiring a lock (System.Threading.Monitor.Enter or entering a synchronized method) shall implicitly perform a volatile read operation, and releasing a lock (System.Threading.Monitor.Exit or leaving a synchronized method) shall implicitly perform a volatile write operation. See §I.12.6.7.

Then from I.12.6.7:

A volatile read has “acquire semantics” meaning that the read is guaranteed to occur prior to any references to memory that occur after the read instruction in the CIL instruction sequence. A volatile write has “release semantics” meaning that the write is guaranteed to happen after any memory references prior to the write instruction in the CIL instruction sequence.

So entering the lock should prevent (3) from moving to (1). Reading from nonVolatileField still counts as a "reference to memory", I believe. However, the read could still be performed before the volatile write when the lock exits, so it could still be moved to (2).

The C#/CLI memory model leaves a lot to be desired at the moment. I'm hoping that the whole thing can be clarified significantly (and probably tightened up, to make some "theoretically valid but practically awful" optimizations invalid).

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Hi Jon, sorry to hijack this comment thread but this seems like a good place for my question, is there a C# 6 or 7 specification document out somewhere? I know Mads Torgersen mentioned somewhere that he had a draft for C# 6 that he ought to publish but I've never seen if he did. I feel that if anyone knows of such a document it would be you :) – Lasse V. Karlsen Dec 06 '16 at 09:11
  • @LasseV.Karlsen: There's a draft of the C# 6 spec at https://github.com/ljw1004/csharpspec, but it *is* just a draft. We're still finishing up standardizing the C# 5 spec for ECMA, which has knock-on effects for later versions as we're hoping to harmonize between ECMA and MS. – Jon Skeet Dec 06 '16 at 09:16
  • @Damien_The_Unbeliever: Could you take another look? The more eyes on this, the better. – Jon Skeet Dec 06 '16 at 09:17
  • Yep. Happier now. – Damien_The_Unbeliever Dec 06 '16 at 09:18
  • So this means that using `SemaphoreSlim` as a lock (as described in [here](http://stackoverflow.com/questions/40979715/do-semaphores-prevent-instruction-reordering)) will not work, because the critical section can be reordered to occur during the lock within the semaphore's `Wait()` method, when the semaphore is not yet entered, right? – tearvisus Dec 06 '16 at 10:11
  • @tearvisus: I think that's a level of complexity beyond where I'm comfortable to express an opinion, I'm afraid. – Jon Skeet Dec 06 '16 at 10:22
  • *"The C#/CLI memory model leaves a lot to be desired at the moment. I'm hoping that the whole thing can be clarified significantly (and probably tightened up, to make some "theoretically valid but practically awful" optimizations invalid)."* -- In Java, the memory model was sanitized, some "awful" optimizations are still allowed. From my point of view, the weak standardized .NET memory model (weaker than MS's actual memory model on x86/amd64) is similar to Java's current memory model, except for initialization safety (§17.5 final Field Semantics in the Java 8 Language Specification). – acelent Dec 15 '16 at 16:05
  • I agree that the memory model and synchronization topics must be *clarified significantly*, both in the CLI specification, in the C# specification and at least in the documentation of classes within the `System.Threading` and `System.Collections.Concurrent` namespaces and its sub-namespaces. For instance, it's known but not officially documented that [*(...) TPL includes the appropriate barriers when tasks are queued and at the beginning/end of task execution so that values are appropriately made visible.*](https://blogs.msdn.microsoft.com/pfxteam/2012/04/12/asyncawait-faq/#comment-18003). – acelent Dec 15 '16 at 16:13
  • @acelent: I think there are still some significant differences. For example, if you call a method and pass a field as an argument, I believe it's valid for the JIT compiler to inline that method and make each read of the *parameter* into a read of the *field*, which can violate all kinds of reasoning. I don't *think* that's valid in Java, although I'd have to check. – Jon Skeet Dec 15 '16 at 16:14
  • @acelent: Oh, and I'm *trying* to get something done about this, btw. The CLI group isn't meeting at the moment, but I'm hoping to get a white paper organized... – Jon Skeet Dec 15 '16 at 16:14
  • The JIT compiler must not perform such inlining if it cannot prove that multiple non-barred reads to the field, without any barriers in between, will yield the same value, even when other threads change that field in **any** way. I don't know of any (N)UMA architecture which guarantees this. A cached memory value may be evicted due to a core that shares a cache, a preemptive OS's thread scheduler actions, an interrupt routine, etc, so it's possible that a non-barred write might become visible to another core even in a weak memory model architecture. – acelent Dec 15 '16 at 17:28
  • I sincerely hope your effort is realized. In comparison, Java has no ECMA or ISO standard, but its specifications and documentation is quite good regarding the memory model and synchronization utilities. – acelent Dec 15 '16 at 17:29
2

As far as .NET is concerned, entering a monitor (the lock statement) has acquire semantics, as it implicitly performs a volatile read, and exiting a monitor (the end of the lock block) has release semantics, as it implicitly performs a volatile write (see §12.6.5 Locks and Threads in Common Language Infrastructure (CLI) Partition I).

volatile bool areWeThereYet = false;

// In thread 1
// Accesses, usually writes: create objects, initialize them
areWeThereYet = true;

// In thread 2
if (areWeThereYet)
{
    // Accesses, usually reads: use created and initialized objects
}

When you write a value to areWeThereYet, all accesses before it were performed and not reordered to after the volatile write.

When you read from areWeThereYet, subsequent accesses are not reordered to before the volatile read.

In this case, when thread 2 observes that areWeThereYet has changed, it has a guarantee that the following accesses, usually reads, will observe the other thread's accesses, usually writes. Assuming there is no other code messing with the affected variables.

As for other synchronization primitives in .NET, such as SemaphoreSlim, although not explicitly documented, it would be rather useless if they didn't have similar semantics. Programs based on them could, in fact, not even work correctly in platforms or hardware architectures with a weaker memory model.

Many people share the thought that Microsoft ought to enforce a strong memory model on such architectures, similar to x86/amd64 as to keep the current code base (Microsoft's own and those of their clients) compatible.

I cannot verify myself, as I don't have an ARM device with Microsoft Windows, much less with .NET Framework for ARM, but at least one MSDN magazine article by Andrew Pardoe, CLR - .NET Development for ARM Processors, states:

The CLR is allowed to expose a stronger memory model than the ECMA CLI specification requires. On x86, for example, the memory model of the CLR is strong because the processor’s memory model is strong. The .NET team could’ve made the memory model on ARM as strong as the model on x86, but ensuring the perfect ordering whenever possible can have a notable impact on code execution performance. We’ve done targeted work to strengthen the memory model on ARM—specifically, we’ve inserted memory barriers at key points when writing to the managed heap to guarantee type safety—but we’ve made sure to only do this with a minimal impact on performance. The team went through multiple design reviews with experts to make sure that the techniques applied in the ARM CLR were correct. Moreover, performance benchmarks show that .NET code execution performance scales the same as native C++ code when compared across x86, x64 and ARM.

acelent
  • 7,965
  • 21
  • 39