Guten Tag

Ich würde gerne mal wissen, wie man einen Vorgang asynchron ausführt, also dass er den aufrufenden Thread nicht blockiert. Ich habe nämlich einige Methoden in meiner DLL, welche manchmal etwas länger dauern. Was muss ich dann in meinen Subs/Functions einfügen damit das alles asynchron läuft.

Vielen Dank im Voraus

Breadsoft

msdn.microsoft.com/de-de/library/system.threading.tasks.task (.NET 4.5 bzw. Async CTP)
oder msdn.microsoft.com/de-de/library/hh191564.aspx bzw. msdn.microsoft.com/en-us/library/hh156513.aspx (alles :NET 4.5/Async CTP)
oder msdn.microsoft.com/de-de/library/system.action und msdn.microsoft.com/de-de/library/bb534960.aspx

Wieso schreibst du bei Task 4.5 hin? Das gibts schon länger. Außerdem bin ich total dagegen jedem Anfänger nur noch Async Schlüsselwort zu zeigen. Es gibt jede Menge anderer Features die .Net anbietet. Und das wichtigste wäre dabei wohl immer noch nen simpler Thread: msdn.microsoft.com/de-de/libra…tem.threading.thread.aspx
Dann gibts noch für Schleifen usw. um diese optimiert arbeiten zu lassen: msdn.microsoft.com/en-us/libra…ading.tasks.parallel.aspx
Außerdem msdn.microsoft.com/de-de/libra…threading.threadpool.aspx

Außerdem findest im Netz zahlreiche Anleitungen... einfach mal googlen. Bin in google gleichma auf die hier gestoßen(nur als Beispiel - ist aber c# aber Prinzip ist das Selbe): 1 2

Wie die Links von AliceDevil zeigen , gibt es eine Unmenge an Möglichkeiten das zu bewerkstelligen.

Für diejenigen, die z.B. aus Kompatibilitätsgründen noch nicht auf die schöne neue Task-Welt umsteigen möchten , gibt es noch die Wahl zwischen
- Backgroundworker (für mich mittlerweile obsolet)
- Threadpool Threads (kurze Laufdauer) , z.B. über Control.BeginInvoke
- den guten alten Thread

Beispiel für Letzteren:

Oft ist es nötig zu wissen wann der Thread fertig ist: in dem Fall ein Event auslösen oder dem Thread einen Delegaten ( die Adresse einer Funktion) mitgeben die er aufrufen soll wenn er sich beendet. Kommt letztendlich aufs Gleiche raus.

Es gibt 3 Muster, nach denen man arbieten kann, was asynchrone Operationen betrifft.

Event-based Asynchronous Pattern (EAP) <-- Bisher am häufigsten verwendet
Asynchronous Programming Model (APM)
Task-based Asynchronous Pattern (TAP; nicht Async CTP, so hieß die Community Preview)

Mehr Infos hier: msdn.microsoft.com/en-us/library/jj152938.aspx

Das Neueste zu verwenden muss aber nicht immer gut/das Beste sein. Es gibt Gründe, ältere Methoden zu verwenden. Ich zitiere hier mal aus der_kurts Signatur:

Ich darf zum Brotschneiden kein Messer benutzen, denn "Messer ist veraltet", heute nimmt man eine Brotschneidemaschine, die kann viel mehr...

Führt Euch das mal vor Augen.

Hier mal ein paar Codes, die das gleiche asynchron erledigen:

Event-based:

Task-based:(APM ausgelassen, da der WebClient dieses nicht unterstützt)

Einen Verleich von allen drei Patterns findet Ihr beim "Mehr Infos"-Link weiter oben im Post.

Natürlich sieht das untere leichter und schöner aus. "Schöner" ist es auch. Beide Patterns haben aber ihre Schwächen. Das obere Pattern braucht einen Callback-Sub, den man aber auch in eine Lambda-Expression auslagern kann:


Wenn man einen einfachen Thread verwendet, lässt sich ein Event-basiertes system leichter implementieren. Verwenden (besonders für externe Leute) lässt sich aber das TAP schöner. Intern ist TAP übrigens Callback-Basiert (ist "nur" eine Compilererweiterung; einfach mal mit dem Reflector schauen, was der daraus macht).

Trotzdem fragt sich jemand, der noch nie normales Threading verwendet hat: "Wie geht das? Warum verlässt er bei Await den Sub und macht dann hinterher weiter? Was sind das für komische Tasks? Wie geht das überhaupt, dass der das im Hintergrund macht? Was ist hier los?"

Noch schlimmer wird es, wenn dieser Jemand nicht einmal die Grundlagen vollständig beherrscht: "Was ist dieses (Of Bla)? Callback? Delegate? IProgress(Of T)? Interface? CancellationToken? SynchronizationContext? Wie soll man das benutzen??"

Der TAP-Kram erfordert weitaus mehr Hintergrundwissen als andere Alternativen (Event-based, Thread-Klasse, Backgroundworker, usw.).

Warum also kein TAP?
Dagegen:
- Schwerer zu verstehen (einfach über all Async und Await hinklatschen macht es um Welten schlimmer, als wenn man einfach Eventbasiert arbeiten würde)
- Erst ab .NET 4.0 mit Targeting Pack und 4.5 "nativ" nutzbar. (Ja, @Samur Aran:, das ist ein Nachteil. ;))
Dafür:
- Skalierbarer, wenn richtig verwendet (besonders auf Server-Multicore-Prozessoren)
- Ist in der WinRT (die neue API für Metro-Apps) der Standard für asynchrone Operationen; "Zukunftssicher"

@Breadsoft: Ich würde dir den BackgroundWorker empfehlen. Der lässt sich einfach verwenden und ist auch noch aktuell.

hmm - grad der Backgroundworker ist doch die letzte Krücke. Da kann man ja nichtmal typisierte Argumente an die parallel auszuführende Methode übergeben.

Dann lieber GenerischerDelegate.BeginInvoke().

Jo, bisserl was wissen muß man halt, wenn man herumthreadeln will. Vor allem 2 Dinge:
1: Das Gui darf nicht aussm Nebenthread aufgerufen werden
2: Ein Thread kann niemals etwas zurückgeben. Weil zum Zurückgeben müsste ja auf den Thread gewartet werden, und dann wäre er ja nicht parallel.
Ein Thread kann immer nur seine Ergebnisse weiterleiten - ob nun als Event gestaltet, als Callback, als Task-Continuation oder mit dieser listigen Await-Geschichte.

nochmal zum BW: Alle Threading-Varianten können typisierte Argumente übermitteln, nur der BW nicht. Also der war schon Schrott, als er herausgekommen ist - ein Spielzeug für Förmchen-Klickser, die sich Threading aufs Form ziehen wollten, und die sich keine Mühe damit geben, den Form-Code einfach zu halten.
In einer Dll hat der BW garnix verloren, es ist ja eine Component.

Aber die brauchbareren Ansätze wurden ja genannt.

im Anhang is mal meine Klasse zum Downloaden einer Datei.

Mein Problem ist ja folgendes: Wenn ich bei Form_Shown den Download einer in einem anderen Thread starte, kommt gleich die Fehlermeldung wegen dem Threadübergreifenden Zugriff. Wenn ich den Thread weglasse, Reagiert die form nicht mehr.
Ich hoffe ihr könnt mir auch verbesserungsvorschläge für meinen(wahrscheinlich schlecht geschriebenen) Code.

(ich nutze die Forums-Funktion zum Anzeigen von Code nicht, weil das bei mir total falsch angezeigt wird.)

Breadsoft schrieb:

kommt gleich die Fehlermeldung wegen dem Threadübergreifenden Zugriff.

War schon mal da, oder?

und wie mache ich das bei events?
weil ich versuche die eigenschaften der controls im hauptthread in einem event zu ändern

Task.Await - schon vergessen?

also muss ich das event als Awaitable deklarieren, und das event dann mit Invoke & Await ausführen?

im gegebenen Await-Sample - kommt da iwas von Invoke vor?

ich hab das schon mit Await versucht nur bei mir hats nich geklappt

5 Regeln für sinnvolle Fragen

Weiter kannichdir nicht helfen, weil ich hab kein 2012

kannst du mir dann wenigstens beim Zugriff auf Controls aus einem anderen Thread, als den Thread für den sie erstellt wurden?

Du solltest Deine Posts ruhig mal lesen.

RodFromGermany schrieb:

VB.NET-Quellcode

1. Me.Invoke() (Sub() Me.TextBox1.Text = "Bla")

Okay danke vorher hat das mit Invoke nich geklappt jetzt aber irgendwie schon

EDIT: Hätte aber nochmal ne Frage. Im Anhang is nochmal meine Klasse. Kann es sein das der Code das vielzu langsam runterlädt oder ob der code irgendwie schlecht geschrieben ist?

In der aus dem anderen Thread aufgerufenen Prozedur machst Du Dir solch eine Invoke-Sub und packst alle entsprechenden Änderungen rein.
Wenn das zu viel wird, machst Du Dir eine separate Sub und rufst die im Invoke auf.

Breadsoft schrieb:

Kann es sein das der Code das vielzu langsam runterlädt oder ob der code irgendwie schlecht geschrieben ist?

jo, das kann sein.
Du liest ja jedes Byte einzeln aussm ResponseStream, und schreibstes in den FileStream. jedes einzeln!

guggemol Stream-Konzepte, wie man blockweise von einen Stream in den anneren schreibt. Also 1024 Bytes dürfens schon sein, als PufferGröße.
Auch würde ich Using-Blöckse empfehlen, um Response, ResponseSTream, Filestream zuverlässig freizugeben.

Auweiaweia!
nicht nur liest du jedes Byte einzeln aus, sondern für jedes einzelne Byte sendest du das DownloadProgressChanged-Event. Das sammeln sich bei einem Megabyte schon so einige Eventse zusammen.
Und jedes einzelne wird vmtl. per .Invoke (anstatt .BeginInvoke) in den MainThread transferiert - jo, so bremst man sich wirkungsvoll aus.

Also auch Threading-Erfahrene bitte aufmerken:

wichtige Information schrieb:

bei Control.Invoke() wartet der Nebenthread, bis der Mainthread den Delegaten ausgeführt hat. In diesem Fall wird also nicht der Mainthread blockiert, sonnern grad annersrum: Es wird der NebenThread blockiert.
Was ja auch nicht Sinn von Nebenläufigkeit sein kann.

Control.BeginInvoke() sollte also die Standard-Variante des Invokings sein, und Control.Invoke() nur in besonderen Ausnahmefällen (grob gesagt: ungefähr nie).

Danke dass du mir die tipps gegeben hast.
Ich hab mich mal rangesetzt und ein bisschen dran gearbeitet.

Der verbesserte Code ist nochmal im Anhang.

Bei der For-Schleife weiß ich jetzt nicht ob die so noch richtig ist weil ich ja nicht mehr jedes byte einzeln auslese.
Auf weiter Verbesserungen würde ich mich freuen.

EDIT: Warum kann man HttpWebRequest nicht in einem Using-Block verwenden?