[From sandbox] Lock with priorities in .NET

[From sandbox] Lock with priorities in .NET


Each programmer using more than one thread in his program encountered synchronization primitives. In the context of .NET, there are a lot of them, I won’t list them, MSDN .

I had to use many of these primitives, and they perfectly helped to cope with the tasks. But in this article I want to tell you about the usual lock in the desktop application and how a new (at least for me) primitive appeared, which can be called PriorityLock.

Problem


When developing a high-load multi-threaded application, a manager appears somewhere that processes innumerable threads. So it was with me. And this manager was working, processing tons of requests from many hundreds of threads. And everything was good for him, and inside he worked the usual lock.

Then one day the user (for example, I) presses a button in the application interface, the stream flies to the manager (not the UI stream of course) and expects to see a super friendly reception, but instead he is met by Aunt Klava from the most dense registry of the most densely polyclinic with the words “I don't give a damn who sent you I still have 950 people like you. Go and go to them. I don't care how you figure it out. ” This is how lock in .NET works. And everything seems to be fine, everything will be executed correctly, but the user clearly did not plan to wait a few seconds for an answer to his action.

At this sentimental story ends and begins to solve a technical problem.

Solution


Having studied the standard primitives, I did not find a suitable option. Therefore, I decided to write my own lock, which would have a standard and high input priority. By the way, after writing, I also studied nuget, I did not find anything like that there, although I was probably looking bad.

For writing such a primitive (or no longer primitive) I needed SemaphoreSlim, SpinWait and Interlocked operations. In the spoiler, I gave the first version of my PriorityLock (only synchronous code, but it is the most important one), and explanations for it.

Hidden text
In terms of synchronization, there are no discoveries, while someone in the lock, others can not enter. If high priority has arrived, it is allowed to wait for those who are waiting for low priority.

Class LockMgr, it is proposed to work with it in your code. That he is the very object of synchronization. Creates Locker and HighLocker objects, contains semaphores, SpinWaits, counters wanting to get into the critical section, current stream and recursion counter.

  public class LockMgr
 {
  internal int HighCount;
  internal int LowCount;
  internal thread CurThread;
  internal int RecursionCount;

  internal readonly SemaphoreSlim Low = new SemaphoreSlim (1);
  internal readonly SemaphoreSlim High = new SemaphoreSlim (1);
  internal SpinWait LowSpin = new SpinWait ();
  internal SpinWait HighSpin = new SpinWait ();

  public locker highlock ()
  {
  return new HighLocker (this);
  }
  public Locker Lock (bool high = false)
  {
  return new Locker (this, high);
  }
 }
  

The Locker class implements the IDisposable interface. To implement recursion when locking it, we remember the thread Id, then check it. Further, depending on the priority, in the case of high priority, we immediately say that we have arrived (we increase the HighCount counter), we get the High semaphore, and wait (if necessary) to release the lock from the low priority, after which we are ready to receive the lock. In the case of a low priority, it receives the Low semaphore, then we wait for the completion of all high priority streams, and, taking the High semaphore for a while, we increase the LowCount.

It is worth mentioning that the meaning of HighCount and LowCount is different, HighCount displays the number of priority threads that came to lock when LowCount only means that the flow (one and only) with low priority went into lock.

  public class Locker: IDisposable
 {
  private readonly bool _isHigh;
  private LockMgr _mgr;

  public Locker (LockMgr mgr, bool isHigh = false)
  {
  _isHigh = isHigh;
  _mgr = mgr;
  if (mgr.CurThread == Thread.CurrentThread)
  {
  mgr.RecursionCount ++;
  return;
  }
  if (_isHigh)
  {
  Interlocked.Increment (ref mgr.HighCount);
  mgr.High.Wait ();
  while (Interlocked.CompareExchange (ref mgr.LowCount, 0, 0)! = 0)
  mgr.HighSpin.SpinOnce ();
  }
  else
  {
  mgr.Low.Wait ();
  while (Interlocked.CompareExchange (ref mgr.HighCount, 0, 0)! = 0)
  mgr.LowSpin.SpinOnce ();
  try
  {
  mgr.High.Wait ();
  Interlocked.Increment (ref mgr.LowCount);
  }
  finally
  {
  mgr.High.Release ();
  }
  }
  mgr.CurThread = Thread.CurrentThread;
  }

  public void Dispose ()
  {
  if (_mgr.RecursionCount & gt; 0)
  {
  _mgr.RecursionCount--;
  _mgr = null;
  return;
  }
  _mgr.RecursionCount = 0;
  _mgr.CurThread = null;
  if (_isHigh)
  {
  _mgr.High.Release ();
  Interlocked.Decrement (ref _mgr.HighCount);
  }
  else
  {
  _mgr.Low.Release ();
  Interlocked.Decrement (ref _mgr.LowCount);
  }
  _mgr = null;
  }
 }

 public class HighLocker: Locker
 {
  public HighLocker (LockMgr mgr): base (mgr, true)
  {}
 }
  


Using an object of class LockMgr turned out very concise. The example clearly shows the possibility of reusing _lockMgr inside the critical section, and the priority is no longer important.

  private PriorityLock.LockMgr _lockMgr = new PriorityLock.LockMgr ();

 public void LowPriority ()
 {
  using (_lockMgr.Lock ())
  {
  using (_lockMgr.HighLock ())
  {
//your code
  }
  }
 }

 public void HighPriority ()
 {
  using (_lockMgr.HighLock ())
  {
  using (_lockMgr.Lock ())
  {
//your code
  }
  }
 }
  

So I solved my problem. The processing of user actions has become executed with high priority, no one was hurt, everyone won.

Asynchrony


Since the objects of the SemaphoreSlim class support asynchronous waiting, I also added this possibility to myself. The code differs minimally and at the end of the article I will provide a link to the source code.

It is important to note here that Task is not tied to a stream in any way; therefore, it is impossible to similarly implement asynchronous reuse of a lock. Moreover, the property Task.CurrentId as described MSDN does not guarantee anything. This ended my options.

In search of a solution, I came across a project NeoSmart.AsyncLock , in the description of which support was shown to reuse asynchronous lok. Technically, reuse works. But unfortunately the lock itself is not a lock. Be careful if you use this package, you know, it does NOT work correctly!

Conclusion


The result was a class that supports synchronous operations with reuse, and asynchronous operations without reuse. Asynchronous and synchronous operations can be used side by side, but cannot be used together! All because of the lack of support for re-using the asynchronous version.

I hope I am not alone in such problems and my decision will be useful to someone. I put the library on github and in nuget.

There are tests in the repository that show the performance of PriorityLock. On the asynchronous part of this test, NeoSmart.AsyncLock was checked, and it did not pass the test.

nuget link
Link to github

Source text: [From sandbox] Lock with priorities in .NET