1

Is Monitor class in C# blocks by spinning (user-mode) or by stopping a thread (kernel-mode)?

I was not able to find an answer to this question in the documentation.

I clearly understand how the Monitor interacts with objects. It uses the sync blocks array created by CLR and just manipulates the sync block field of an object to point to a specific sync block. Then the sync block will contain an id of a thread which took the lock, the recursion count (number of times the thread took the look). And the Monitor.Enter will block other threads until the recursion count is 0.

But I do not understand how the blocking will happen. Will the blocked (waiting) threads transition to kernel mode and stop there or will they just spin around wasting CPU?

Sasuke Uchiha
  • 857
  • 2
  • 11
  • 23
  • 1
    it seems like you could test this by creating a couple of threads and have them wait (`Monitor.Enter`) on an unavailable object - and look at your CPU usage; I *suspect* it'll do a couple of speculative spins and then give up and transition to a kernel wait, but ultimately it is an implementation detail - in .NET Framework, at least, they are all `InternalCall` to the runtime; the implementation for .NET Core should be available on github, though – Marc Gravell Apr 15 '20 at 08:16
  • 1
    .NET Core and Mono too: https://github.com/dotnet/runtime/blob/4f9ae42d861fcb4be2fcd5d3d55d5f227d30e723/src/coreclr/src/System.Private.CoreLib/src/System/Threading/Monitor.cs / https://github.com/dotnet/runtime/blob/7302fa490d4da1b2b806dfeb3d778636f9cd0121/src/mono/netcore/System.Private.CoreLib/src/System/Threading/Monitor.cs; looks like it is implemented by JIT_MonEnter in the VM – Marc Gravell Apr 15 '20 at 08:19
  • 1
    It spins for a short period first, before calling into the kernel. That, combined with increased pause times on Skylake CPUs, caused [this](https://support.microsoft.com/en-gb/help/4527212/long-spin-wait-loops-in-net-framework-on-intel-skylake) [fun](https://aloiskraus.wordpress.com/2018/06/16/why-skylakex-cpus-are-sometimes-50-slower-how-intel-has-broken-existing-code/) [issue](https://github.com/dotnet/runtime/issues/8744), The assumption being that most locks are either uncontested or contested for only a short period. – canton7 Apr 15 '20 at 08:22
  • Thank you all for the insights. :) – Sasuke Uchiha Apr 15 '20 at 08:28

0 Answers0