Re: BackGroundWorker und Form!

leslie eldrige wrote:
Warum ist das was ich geschrieben habe Unsinn!?

Genau mit SLEEP (in der Methode DoWork) gibst Du Windows genügend
Zeit auch Deine Ereignisse auf der GUI zu verarbeiten (z.B. wie in
meinem Fall ein Cklick, ein Klick auf eine Checkbox). Ohne SLEEP ist
Windows überforder auf Ereignissen (mit niedrigeren Prio) zu
reagieren.

Übrigens das ganze kann man schön mit Peters Beispiel nachvollziehen
sehr gut nachvollziehen:

www.gssg.de -> Visual Basic -> VB.net
-> BackGroundWorker - Threading
-> Thread_Invoke

Man starten die Applikation. Alle Controls sind während der BGW läuft
problemlos ansprechbar. Wenn man aber die SLEEP Funktion aus dem BGW
deaktiviert, dann friert die GUI!

Ich habe das übrigens auch nach Thomas Posting bemerkt und hab seine
Antwort als Hilfreich quitiert. Somit wäre das Thema für mich
erledigt. Ich wollte aber nun mal genauer wissen was da abläuft und
ob es doch nicht eine andere Möglichkeit gebe. Und übrigens es ist
immer gut wenn die Erkenntnisse in der Newsgroup gespeichert bleiben,
dann kann sich einer später viel Zeit ersparen.

PS: Wäre Dir sehr dankbar wenn Du meine Aussagen zuerst technisch
prüfst bevor Du sie als UNSINNIG bezeichnest. Danke schon mal im
Voraus.

Hi Leslie,
du hast scheinbar nicht wirklich verstanden, was multithreading bedeutet.
Dass der Backgroundworker einige Dinge kapselt, ändert nichts an der
Tatsache, dass es sich um multithreading mit allen seinen Besonderheiten
handelt.

Man darf nur nie vergessen, das sich zwei threads parallel un die Ressource
"CPU" bewerben und das Betriebssystem nach jedem beliebigen CPU-Befehl eine
thread unterbrechen kann und die CPU dem anderen thread zuweisen kann. Da
aber eine Sprachanweisung in viele CPU-Befehle "zerlegt" wird, kann eine in
der Sprache eindeutige Anweisung so "zerissen" werden, dass beim
quasiparallelen Zugriff auf die anderen Ressorcen (Speicher, externe Geräte
wie beispielsweise Bildschirm) "unfertige" Zustände vorgefunden und ggf.
manipuliert werden. Das Chaos ist damit unausweichlich.

Der Aus- oder Umweg besteht darin, threadsichere Objekte zu nutzen, die
nicht in komplere Vorgänge eingebunden sind. Das kann beispielsweise eine
Variable vom Werttyp sein, die eindeutig beschrieben und/oder gelesen wird.
Ein anderer Weg ist die Pufferung von Daten (Parameter) mit folgender
Übergabe der Steuerungsanforderung an den anderen thread, der sich um die
Abarbeitung kümmert, wenn er einen definierten Zustand erreicht hat
(Wartezustand). Dieses Prinzip wird mit Invoke realisiert.


--
Viele Grüße

Peter



.

Relevant Pages

  • Re: Help Me!
    ... I thought the thread doing the calculations should ... > sleep() at intervals to allow the Gui to respond. ... the behavior of threads with different priorities id fully ... One of my apps had a thread that updated a GUI. ...
    (comp.lang.java)
  • Re: Help Me!
    ... I thought the thread doing the calculations should ... > sleep() at intervals to allow the Gui to respond. ... the behavior of threads with different priorities id fully ... One of my apps had a thread that updated a GUI. ...
    (comp.lang.java.gui)
  • Re: Win32::GUI and Scrolling Text
    ... else sleep again and repeat. ... It then loops back and starts reading where it left off (if there are ... I don't need this "event handler loop" stuff getting in my way. ... Can I just do a fork and say "Here Mr. TK GUI, ...
    (comp.lang.perl.misc)
  • Re: PATCH/FIX for drivers/cdrom/cdrom.c
    ... race condition, ... man 3 sleep ... man 2 flock ... or in the GUI world I'm firmly assured that the sun shines out of the ...
    (Linux-Kernel)