It is not enough to know what Mutex, Semaphore, and async / await are. You need to know everything from quanta

Very soon, November 29-30 in St. Petersburg and December 06-07 - in Moscow we will launch the sixth .NET seminar . This time on the topic of multithreading and competitiveness. We already wrote about this a couple of times on Habré, but today there is a separate reason for this: the seminar is a real exclusive . The operation of the hybrid synchronization primitive will be described: Monitor



. Yes, the familiar little thing is worthy of a separate report. After all, in his work he takes into account both the processor frequency and the number of cores, takes into account lock convoy / starvation and in general is very complicated.







And at the end of the entertainment article, I’ll propose going through a couple of QUIZs on multithreading.













A small scenario from the workshop



The most important thing that comes from the operating system is thread scheduling. After all, they can work both in parallel with each other (when they are currently running on different cores), and more often (if we are talking about the same threads) - sequentially. After all, the OS does not give much time to execution - to everyone, after which it gives time to others. The second - for this segment - a quantum - a different amount of time can be allocated. For example, depending on which version of the OS we are using: server or user, whether the UI thread is a process thread with the current active window. Thirdly, there are priorities and the concept of “crowding out multitasking”, when your flow, only having received the treasured quantum, can lose it, because another thread with a higher priority formed. It turns out that our application is highly dependent on the environment in which it works. For example, some settlement service will feel best on the server version of the OS (or with the appropriate performance settings) when there are no other services on the machine at all: the quanta will be long, there will be a lot of quantum time.







But here another question arises: if our thread on this configuration sets a kernel-level lock (for example, Semaphore (1)), when the second thread reaches the lock, it gets into this lock, then it will stand in the server OS much longer than it stood would be in custom. Why? Yes, because the server time slice is 6 times longer than the client’s and this thread will first have to wait until the first thread reaches the lock release point, and then when it gets a new quantum.







However, there is help for such a case: when the lock is released, all threads who were expecting it temporarily (by 1 quantum) have priority over other threads and the second thread will receive processor time immediately.







CLRium 6



These three paragraphs are a concise 5% of the 4th report. And he is already rich in information that can be used at all levels: from working with synchronization primitives to working with high-level libraries. And our program is this:







  1. We will look at the types of processes. There are a lot of them, and we use two of them from strength: these are ordinary and ModernApp;
  2. Three reports in a row are operating system-level threads: scheduling on single-core, multi-core systems and NUMA systems. Everywhere the rules are different and this must be taken into account in your work;
  3. Analysis of the operation of synchronization primitives at the quantum time level. You all learned to talk about lock / Mutex / Semaphore in interviews. There is no point in repeating, and therefore we will arm ourselves with timelines and see how quanta are distributed between processors on all synchronization primitives: Kernel-Space, User-Space, and hybrid ones.
  4. A true workshop exclusive: the structure of the Monitor



    primitive. The fact that lock(){}



    revealed in try { } finally { }



    you already knew without me, but what Monitor.Enter



    , Monitor.Leave



    , Monitor.TryEnter



    is Monitor.TryEnter



    is a topic for a separate, tight, full report hell. Believe me, everything inside him is very, very cool. This is a hybrid synchronization primitive that is built to avoid Starvation, excessive lock and lock convoy escapes.
  5. As many as three solid reports on lock-free and wait-free, including the example of reconnaissance drones and air defense, trying to shoot down these drones. And these reports were so liked by HighLoad ++ that they were called to HighLoad ++ in Moscow on November 07-08 .
  6. A series of reports on PLINQ and Async-Await. Everything is also as detailed as possible. Off-road: this good enough on the Internet. Each technology will be told "from the inside": as is customary at CLRium.
  7. And the seminar will be closed by two reports on the library of lock-free collections from Microsoft and Intrinsics (vector instructions for parallelization at the processor level).


Some statistics



We are the largest seminar in the country and in general are not a conference just because we like our format. You do not choose among reports that you will not go to. You go for everything. At the same time, you understand in advance that all the topics of the seminar are interesting to you, because the theme is one. Another record will be set at CLRium 6: 700 people will be present in both cities. About 700 people pump their skills in parallelization and work with competition. And they will go for interviews. Come and you to us :).








All Articles