Zwei Threads ein Kern

  

Liegt es daran, dass ich ein Wait-Handle verwende, das beim Senden einer Nachricht gesetzt wird und nach Abschluss der Verarbeitung wieder freigibt?

Ohne Ihren Code zu sehen, ist es schwer zu sagen, aber aus Ihrer Beschreibung scheint es, dass die zwei Threads, die Sie geschrieben haben, als Co-Routinen fungieren: Wenn der Haupt-Thread läuft, hat der Worker-Thread nichts zu tun und umgekehrt. Es sieht so aus, als wäre der .NET-Scheduler schlau genug, um den zweiten Kern nicht zu laden, wenn dies passiert.

Sie können dieses Verhalten auf verschiedene Arten ändern - zum Beispiel

• indem Sie etwas am Hauptthread arbeiten, bevor Sie auf den Handle warten, oder
• , indem Sie weitere Worker-Threads hinzufügen, die um die Aufgaben konkurrieren, die Ihr Hauptthread veröffentlicht, und beide könnten eine Aufgabe zum Bearbeiten erhalten.

OK, ich habe herausgefunden, was das Problem ist. Der Produzent und Konsument ist in diesem Fall ziemlich genau so schnell. Dies führt dazu, dass der Verbraucher seine gesamte Arbeit schnell beendet und dann zurückläuft, um auf das AutoResetEvent zu warten. Wenn der Produzent das nächste Mal eine Aufgabe sendet, muss er das AutoresetEvent berühren und einstellen.

Die Lösung bestand darin, dem Verbraucher eine sehr kleine Verzögerung hinzuzufügen, wodurch er etwas langsamer als der Produzent wurde. Dies führt dazu, dass der Produzent, wenn er eine Aufgabe sendet, merkt, dass der Konsument bereits aktiv ist und nur in die Worker-Warteschlange schreiben muss, ohne das AutoResetEvent zu berühren.

Das ursprüngliche Verhalten führte zu einer Art Ping-Pong-Effekt, der auf dem Screenshot zu sehen ist.

Dasblinkelight (wahrscheinlich) hat die richtige Antwort.

Abgesehen davon wäre es auch das korrekte Verhalten, wenn einer Ihrer Threads I / O-gebunden ist (das heißt, er hängt nicht auf der CPU) - in diesem Fall haben Sie von der Verwendung mehrerer Kerne nichts zu gewinnen, und .NET ist schlau genug, um nur Kontexte auf einem Kern zu ändern.

Dies ist häufig bei UI-Threads der Fall - es hat nur sehr wenig zu tun, so dass es normalerweise keinen Grund gibt, einen ganzen Kern für sich zu beanspruchen. Und ja, wenn Ihre gleichzeitige Warteschlange nicht richtig verwendet wird, könnte es einfach bedeuten, dass der Haupt-Thread auf den Worker-Thread wartet - auch in diesem Fall müssen die Kerne nicht gewechselt werden, da der ursprüngliche Thread sowieso wartet.

Sie sollten BlockingCollection anstelle von ConcurrentQueue verwenden. . Standardmäßig verwendet BlockingCollection ein ConcurrentQueue unter der Haube, aber es hat eine viel einfacher zu bedienende Oberfläche. Insbesondere wartet es nicht besetzt. Darüber hinaus unterstützt BlockingCollection Stornierung , also Ihr Verbraucher wird sehr einfach. Hier ist ein Beispiel:

Die Schleife mit GetConsumingEnumerable führt eine Wartezeit in der Warteschlange aus. Es ist nicht nötig, dies mit einer separaten Veranstaltung zu tun. Es wird auf das Hinzufügen eines Elements zur Warteschlange warten oder es wird beendet, wenn Sie das Löschungs-Token setzen.

Um es normal zu stoppen, rufen Sie einfach _queue.CompleteAdding() auf. Das sagt dem Verbraucher, dass der Warteschlange keine weiteren Einträge hinzugefügt werden. Der Benutzer wird die Warteschlange leeren und dann beenden.

Wenn du früh aufhören willst, rufe einfach _cancellation.Cancel() an. Das bewirkt, dass GetConsumingEnumerable beendet wird.

Im Allgemeinen sollten Sie ConcurrentQueue nicht direkt verwenden. BlockingCollection ist einfacher zu verwenden und bietet eine gleichwertige Leistung.