Hi,

ich habe schon das ein oder andere mal mit einem BackgroundWorker gearbeitet.
Weiterhin habe ich schon immer mal wieder gelesen das man eigene Threads erstellen kann um bestimmte Aufgaben abzuarbeiten.

Aber was ich nicht versetehe ist wann es von Vorteil ist einen Thread zu erstellen und keinen Backgroundworker?
Das ich bei dem Thread die Prio selbst wählen kann währe warscheinlich ein Vorteil, aber wird ja sicherlich nicht der einzige Vorteil sein.

Kann man pauschal sagen das man bei einer synchronen/asynchronen abarbeitung eine der beiden bevorzugen sollte oder gibt es andere Indizien um zu entscheinden was man wählen sollte?

Ich habe ein simples Programm ersetllt welches mir alle Dateien auf der Festplatte/USB Stick/ Netzlaufwerk,... anzeigt.
Das Programm habe ich einmal im Backgroundworker ausgeführt und einmal für jedes Speichermedium ein eigenen Thread erzeugt, aber ich kann nicht sagen das eine der beiden Methoden sonderlich schneller ist als die andere ( ich habe auch nicht wirklich die Zeit gemessen ).

anbei mal die Codeschnipsel :

Backgroundworker :




und hier die Threadmethode :

der BackgroundWorker arbeitet ja auch in einem neuen Thread so ist es nicht

und das ReportProgress Event wird auch nicht direkt nach dem Aufruf von ReportProgress aufgerufen, da ist eine verzögerung da und bei mir war das mal zu oft nacheinander, dann wurde es nur alle 100 mal oder so aufgerufen, das würde in einem Thread nicht passieren...meine ich
Mit einem BackgroundWorker bist du halt wesentlich schneller bedient bei einem thread wird oft etwas mehr Code benötigt, aber jenachdem hast du mit diesem auch mehr möglichkeiten, z.B. ist es einfacher die Threads dynamisch hinzuzufügen, wie einen Backgroundworker...

also: Ich benutz lieber Threads

das ist nur mal meine Meinung und Meinungen sind verschieden

hätte nicht gedacht das es keinen großen unterschied gibt zwischen den beiden methoden prozesse "auszulagern".
ich denke ich werde wohl in zukunft die Thread-Methode wählen um zeitintensive funktionen auszuführen,da sie recht einfach "mehrfach" aufrufbar sind. die backgroundworker warscheinlich auch, aber dort "nervt"mich das vorbereiten der events ziemlich, wenn man die sache dynamisch gestalten möchte.

kann mir aber immernoch nicht vorstellen das es keine großen unterschiede gibt, schließlich wäre es nicht notwendig gewesen beide sachen zu entwickeln/ implementieren wenn beides fast identisch ist.

aber vielleicht finde ich ja noch was anderes raus.

mfg

Es gibt mehrere Unterschiede.

Der BackgroundWorker verwendet bei der Arbeit einen Thread aus den Threadpool, während die manuelle Methode selbst einen erzeugt. Durch die "nach außen geführte" Komplettsteuerung arbeitet die manuelle Version etwas langsamer als der Threadpool, was sich aber nur bei längeren Operationen bemerkbar macht. Desweiteren liegt ein Unterschied in der Threadsicherheit: Die Ereignisse des BackgroundWorkers sind automatisch threadsicher, was bedeutet, dass Aufrufe wie Label1.Text = "hallo" automaitsch an den UI-Thread abgegeben werden. Verwendest du die manuelle Variante, wirst du feststellen, dass es Exceptions hagelt, wenn du den genannten Aufruf ohne Vorkehrungen ausführst. Und gleich vorweg: Stelle niemals die Option "CheckForIllegalCrossThreadCalls" auf False - dies unterdrückt die Fehlermeldungen. Dummerweise führt das auch zu unvorhersagbaren Zuständen und Fehlern, die _sehr_ schwer zu finden sind. Die Vorkehrungen für die Threadsicherheit stehen im MSDN-Artikel "Threadsicheres Aufrufen von Windows Forms-Steuerelementen" - das ist ein bisschen mehr als das Vorbereiten des BackgroundWorkers, vor allem wenn nicht nur ein einziges Control angesprochen werden soll, sondern gleich mehrere mit derselben Methode. Das Ganze führt dann schnell man in den recht abstrakten Bereich der Reflexion.
Die genannten Unterschiede sind nicht die einzigen, aber für den Anfang sollte das erstmal reichen.