Ich versuche das .NET Backgroundworker-Objekt in einer Anwendung zu verwenden, die ich gerade entwickle.
Das gesamte Material im Internet sagt, dass dieses Objekt im "Hintergrund" läuft, aber nirgendwo konnte ich bestätigen, dass dieser Hintergrund-Thread tatsächlich in einem Modus mit "niedriger Priorität" läuft . Diese Frage tritt auf, weil in Windows (ich nehme an) eine Hintergrundaufgabe in einem "normalen" oder "unter normalen" oder "niedrigen" Prioritätsmodus laufen kann.
In meiner Anwendung habe ich versucht, die Priorität selbst in der DoWork-Funktion durch Aufruf festzulegen ...
%Vor%...
aber das scheint keine Wirkung zu haben. Ignoriert der Hintergrundarbeiter diesen Anruf?
Ich würde gerne etwas mehr erklären:
Meine Anwendung ist ein Internet-Client, der Echtzeitdaten über Temperatur, Luftfeuchtigkeit usw. von einer Kammer sammelt und mit
auf eine Webseite hochlädt (kein Web-Service) system.net.webclient.UploadValuesAsync(...) ruft
Ich habe die Anwendung so geschrieben, dass die Client-GUI die Daten aus der Kammer sammelt, sie mit einem Zeitstempel versehen und sie dann für den Upload in die Warteschlange stellt.
...
%Vor%Die Dowork-Funktion des Backgroundworker wird aus der Warteschlange entfernt und dann wie folgt hochgeladen ...
..............
%Vor%................
Wenn ich das Programm ausführe, finde ich, dass das Debug-Fenster immer stoppt, wenn UploadValuesAsync aufgerufen wird. Ich hatte auch Debug-Anweisungen hinzugefügt, um zu sehen, wie viele Lesungen zu jeder Zeit in der Warteschlange sind. Wenn diese Aufgabe wirklich mit niedriger Priorität ausgeführt wird, erwarte ich, dass die Anzahl der Warteschlangen beim Erfassen der Daten schnell ansteigt und dann nur abnimmt, wenn der Vordergrund inaktiv ist und keine Daten erfasst werden. Aber das ist nicht der Fall. Sobald ein Lesevorgang zur Warteschlange hinzugefügt wird, wird er aus der Warteschlange genommen und hochgeladen. Also ist die Anzahl der Warteschlangen immer 1 oder 0!
Stimmt etwas nicht mit meiner Herangehensweise? Sollte ich das Hintergrundarbeiterobjekt überhaupt nicht verwenden?
BTW, das ist in einem Dual-Core-Laptop mit Windows XP.
Nur um hinzuzufügen, was Jon und Marc bereits gesagt haben:
Hintergrundthreads haben keine niedrigere Priorität. Der Unterschied zwischen Vordergrund- und Hintergrundthreads besteht darin, dass die CLR den Prozess herunterfährt, sobald keine Vordergrundthreads mehr ausgeführt werden. Threadpool-Threads sind Hintergrundthreads.
Sie können tatsächlich die Priorität eines Thread-Pool-Threads festlegen, aber da Sie als Nächstes keine Kontrolle darüber haben, welcher Thread-Pool-Thread Ihre Aufgabe tatsächlich ausführt, ist es nicht ratsam, dies zu tun. Wenn Sie Threads mit einer bestimmten Priorität benötigen, sollten Sie sie mit dem Thread-Typ erstellen und die Priorität für die Instanz wie gewünscht festlegen.
Ja, etwas stimmt nicht mit Ihrer Herangehensweise - Sie sind im Grunde eine enge Schleife, wenn die Warteschlange leer ist. Was auch immer die Thread-Prioritäten sind, das ist eine schlechte Idee.
Es ist nichts falsch daran, einen Hintergrund-Worker zu verwenden, aber das Ein- / Ausreihen sollte eigentlich nur eine Producer / Consumer-Warteschlange verwenden, die blockiert, wenn Sie versuchen, die Warteschlange zu entfernen, wenn nichts bereit ist.
Ich habe eine Beispielimplementierung einer Producer / Consumer-Warteschlange in meinem Threading-Lernprogramm - siehe etwa auf halbem Weg die verlinkte Seite. Du wirst übrigens einen Weg brauchen, um den Auslagerungsprozess zu erklären, dass es fertig ist. (Beispielsweise wird ein NULL-Verweis oder ein anderer spezieller Wert in die Warteschlange eingereiht.) Dieser Code wurde vorgenerisch geschrieben, sollte aber leicht zu aktualisieren sein.
Es erhebt keinen Anspruch auf niedrige Priorität - Hintergrund bedeutet a: nicht der UI-Thread und b: es wird einen Prozess nicht am Leben erhalten. In Wirklichkeit bezieht sich das wahrscheinlich auf ThreadPool threads.
Wenn Sie einen bestimmten Prioritäts-Thread haben wollen, dann benutzen Sie Ihr eigenes Thread -Objekt - aber ich würde das selbst normalerweise nicht empfehlen ...
Zusätzlich - "Hintergrund" bedeutet nicht "im Leerlauf". Selbst auf einer Single-Core-Maschine werden Sie wahrscheinlich sehen, dass beide Threads so viel Zeit bekommen (wenn sie es wollen). Mehr noch auf Multi-Core.
Vielleicht möchten Sie sich diese Implementierung von Arbeitsthreads ansehen. Es hat Konstruktoren zum Festlegen des Namens des Threads, der Priorität des Threads und ob der Thread ein Hintergrundthread ist, geschützt.
Tags und Links .net multithreading backgroundworker