Sehr bald, vom 29. bis 30. November in St. Petersburg und vom 6. bis 7. Dezember in Moskau, werden wir das sechste .NET-Seminar starten. Diesmal zum Thema Multithreading und Wettbewerbsfähigkeit. Wir haben bereits ein paar Mal über Habré darüber geschrieben, aber heute gibt es einen anderen Grund dafür: Das Seminar ist wirklich exklusiv . Die Funktionsweise des Hybridsynchronisationsprimitivs wird beschrieben: Monitor . Ja, das vertraute kleine Ding verdient einen separaten Bericht. Schließlich berücksichtigt er bei seiner Arbeit sowohl die Prozessorfrequenz als auch die Anzahl der Kerne, berücksichtigt den Konvoi / Hunger des Schlosses und ist im Allgemeinen sehr kompliziert.
Und am Ende des Unterhaltungsartikels werde ich vorschlagen, ein paar QUIZs zum Thema Multithreading durchzugehen.
Ein kleines Szenario aus dem Workshop
Das Wichtigste, was vom Betriebssystem kommt, ist die Thread-Planung. Schließlich können sie sowohl parallel (wenn sie derzeit auf verschiedenen Kernen ausgeführt werden) als auch häufiger (wenn es sich um dieselben Threads handelt) nacheinander arbeiten. Schließlich gibt das Betriebssystem der Ausführung nicht viel Zeit - allen, danach gibt es anderen Zeit. Dem zweiten - für dieses Segment - einem Quantum - kann eine andere Zeitspanne zugewiesen werden. Abhängig davon, welche Version des Betriebssystems wir verwenden: Server oder Benutzer, ob der UI-Thread ein Prozessthread mit dem aktuell aktiven Fenster ist. Drittens gibt es Prioritäten und das Konzept des „Verdrängens von Multitasking“, wenn Ihr Flow, der nur das geschätzte Quantum erhalten hat, es verlieren kann, weil ein weiterer Thread mit einer höheren Priorität gebildet. Es stellt sich heraus, dass unsere Anwendung stark von der Umgebung abhängt, in der sie funktioniert. Beispielsweise fühlen sich einige Berechnungsdienste auf der Serverversion des Betriebssystems (oder mit den entsprechenden Leistungseinstellungen) am besten an, wenn überhaupt keine anderen Dienste auf dem Computer vorhanden sind: Die Quanten sind lang, es wird viel Quantenzeit geben.
Hier stellt sich jedoch eine andere Frage: Wenn unser Thread in dieser Konfiguration eine Sperre auf Kernelebene erstellt (z. B. Semaphore (1)), gelangt der zweite Thread zur Sperre und gelangt in diese Sperre, dann bleibt er viel länger im Server-Betriebssystem als er war wäre in der Gewohnheit. Warum? Ja, da die Server-Zeitscheibe sechsmal länger ist als die des Clients und dieser Thread zuerst warten muss, bis der erste Thread den Lock-Release-Punkt erreicht, und dann, wenn er ein neues Quantum erhält.
In einem solchen Fall gibt es jedoch Hilfe: Wenn die Sperre aufgehoben wird, haben alle Threads, die sie vorübergehend erwartet haben (um 1 Quantum), Vorrang vor anderen Threads, und der zweite Thread erhält sofort Prozessorzeit.
CLRium 6
Diese drei Absätze machen 5% des 4. Berichts aus. Und er ist bereits reich an Informationen, die auf allen Ebenen verwendet werden können: von der Arbeit mit Synchronisationsprimitiven bis zur Arbeit mit Bibliotheken auf hoher Ebene. Und unser Programm ist folgendes:
- Wir werden uns die Arten von Prozessen ansehen. Es gibt viele von ihnen, und wir verwenden zwei davon aus Stärke: diese sind gewöhnlich und ModernApp;
- Drei Berichte hintereinander sind Threads auf Betriebssystemebene: Planung auf Single-Core-, Multi-Core-Systemen und NUMA-Systemen. Überall sind die Regeln unterschiedlich und dies muss bei Ihrer Arbeit berücksichtigt werden.
- Analyse der Arbeit von Synchronisationsprimitiven auf Quantenzeitebene. Sie alle haben in Interviews gelernt, über Lock / Mutex / Semaphore zu sprechen. Es macht keinen Sinn, dies zu wiederholen, und deshalb werden wir uns mit Zeitleisten ausrüsten und sehen, wie Quanten zwischen Prozessoren auf allen Synchronisationsprimitiven verteilt sind: Kernel-Space, User-Space und Hybrid-Primitive.
- Ein wahrer exklusiver Workshop: die Struktur des
Monitor Grundelements. Die Tatsache, dass lock(){} in try { } finally { } enthüllt lock(){} , wussten Sie bereits ohne mich, aber was Monitor.Enter , Monitor.Leave , Monitor.TryEnter in Monitor.TryEnter wird Monitor.TryEnter ist ein Thema für eine separate, dichte, vollständige Berichtshölle. Glauben Sie mir, alles in ihm ist sehr, sehr cool. Dies ist ein hybrides Synchronisationsprimitiv, das entwickelt wurde, um Hunger, übermäßiges Sperren und Entkommen von Konvois zu vermeiden. - Bis zu drei solide Berichte über Lock-Free und Wait-Free, einschließlich des Beispiels von Aufklärungsdrohnen und Luftverteidigung, die versuchen, diese Drohnen abzuschießen. Und diese Berichte waren bei HighLoad ++ so beliebt, dass sie am 07. und 08. November zu HighLoad ++ in Moskau aufgerufen wurden.
- Eine Reihe von Berichten über PLINQ und Async-Await. Alles ist auch so detailliert wie möglich. Nicht um die Uhr: Dieses Zeug reicht im Internet. Jede Technologie wird "von innen" erzählt: wie es bei CLRium üblich ist.
- Zum Abschluss des Seminars werden zwei Berichte über die Bibliothek sperrfreier Sammlungen von Microsoft und Intrinsics (Vektoranweisungen für die Parallelisierung auf Prozessorebene) abgeschlossen.
Einige Statistiken
Wir sind das größte Seminar des Landes und im Allgemeinen keine Konferenz, nur weil uns unser Format gefällt. Sie wählen nicht zwischen Berichten aus, zu denen Sie nicht gehen werden. Du machst alles. Gleichzeitig verstehen Sie im Voraus, dass alle Themen des Seminars für Sie interessant sind, weil Das Thema ist eins. Ein weiterer Rekord wird bei CLRium 6 aufgestellt: 700 Menschen werden in beiden Städten anwesend sein. Rund 700 Menschen pumpen ihre Fähigkeiten in der Parallelisierung und arbeiten mit dem Wettbewerb. Und sie werden Interviews machen. Komm und du zu uns :).