Nabend! (Oder guten Morgen:-)) Ihr erinnert euch noch an den Thread "Aussetzer beim Dateizugriff"?

Habe nun einen etwas größeren Versuch gefahren, um das Ganze "nachzustellen". Habe als "unzuverlässige" Netzwerklaufwerke auch mal den HiDrive von Strato via Internet und auch einen USB Stick an einer Fritzbox mit eingebunden.

Ergebniss:

VB2010 reagiert bei Problemen beim Dateizugriff (egal welcher Art) wesentlich "allergischer", als noch ein VB6. Es kommt im Schnitt zu wesentlich mehr und längeren Aussetzern, die meistens nur die zugreifende Anwendung betreffen, hier aber manchmal sogar ActiveX in getrennten Threads beeinflussen, und in bestimmten Situationen sogar die ganze Maschine in einen 10s "Schluckaufmodus" versetzen können. Mit "Problemen" meine ich hier auch ausdrücklich so etwas "banales" wie Zugriffszeiten im 100-500ms Bereich, die man im normalen Netzwerk nicht kennt. Aber selbst bei Antwortzeiten von nur wenigen ms (weil vielleicht grad mehrere Clients auf eine Dateifreigabe auf einen etwas älteren PC zugreifen), lassen sich deutliche Unterschiede ausmachen.

Richtig "gut" läßt sich sowas anscheinend tatsächlich nur handeln, wenn man tatsächlich jeden Zugriff in einen eigenen Thread auslagert. Natürlich nur mit erheblichen (Design) Aufwand, den so ein MultiThreading mit sich bringt. (Diesbezüglich nochmal herzlichen Dank an meine Helfer aus diesem Forum)

Damit habe ich nun zwar mein ursprüngliches Problem (stotternde Webcams) in den Griff bekommen. Aber: Die Frage nach dem "Warum" bleibt offen!

Hat hier jemand eine Idee, warum VB2010 / Net speziell bei Dateizugriffen in einem Netzwerk diesbezüglich so reagiert? Ich bin doch mit Sicherheit nicht der erste, der darüber gestolpert ist. (Aber ich bin leider einer derjenigen, die wohl noch sehr oft darüber stolpern werden!

Und: Weiß jemand, ob beim ständigen Erzeugen und Beenden von Threads "Folgeschäden" in Form von Speicherfraß auftreten? Sollte man stattdessen vielleicht besser einige wenige "Nebenthreads" erzeugen, die dann aber immer aktiv bleiben? Ich beschäftige mich hauptsächlich mit Programmen, die "NonStop" laufen sollen. Uptimes von teilweise mehreren Monaten sind keine Seltenheit. Da wäre ein "Speicherfresser" natürlich ein KO Kriterium.

Das Problem (bzw. die "Denkaufgabe") sowohl via Async als auch mit nem extra Thread ist jedoch das Gleiche:

Bei vielen kleinen "Hintergrundprozessen" im Programm, die via Timer oder Ereigniss gestartet werden, und nun auf einmal "außerhalb" der jeweiligen Abfolge laufen sollen, bekommt man schlagartig nun auch genau soviele "Baustellen".

Diese Baustellen wollen nun peinlichst genau darauf geprüft werden, WER und WANN und WELCHE Daten braucht bzw. updatet, und wo sich Programmteile dann ev. mit inkonsistenten Daten gegenseitig ausknocken.

Dann sind halt mitunter zusätzliche "Status-Flags" oder manchmal auch regelrechte Locks erforderlich, um den Zustand der Daten genau zu beschreiben, bzw. um sicherzustellen, das möglichst nur EIN Programteil gerade darin arbeitet. Das simpelste Beispiel hierfür sind halt Zugriffsfehler, die natürlich im Mainthread garnicht angezeigt werden können, bevor nicht die Aktion selbst beendet ist. Auch darf natürlich die Weiterverarbeitung oder Anzeige von Daten in Diagrammen nicht schon starten, während ein Thread die Daten immer noch gerade einliest. Teilweise muß ich nun 2 verschiedene Datensets benutzen und zwischen den beiden "umschalten", damit eben doch gleichzeitig eingelesen und auch weiterverarbeitet werden kann. Die Erkenntnis, das man die eigentliche Sub zwar mehrfach gleichzeitig in mehreren Treads benutzen kann, aber einen deklarierten Thread nicht zweimal zur gleichen Zeit laufen haben kann, gehört da schon zu den kleineren Aha-Effekten.

Das sind halt alles nun neu hinzukommende Dinge, die man vorher nicht wirklich beachten mußte, weil die Reihenfolge zwangsweise vorgegeben war.

Andererseits bin ich aber mittlerweile auch wohl "Fan" dieser Threading Geschichte, und mein Programmdesign wird nun zwangsweise ordentlicher, strukturierter und besser durchdacht. Meine Programme fühlten sich von der Bedienung her noch nie so "flüssig" an! :-)) Selbst auf SingleCore Maschinen ist dieser positive Effekt nun deutlich zu sehen. Auch bei schwerwiegenden/dauerhaften Netzwerkproblemen bleibt nun die Bedienoberfläche "intakt", sodaß sich Änderungen an der (ev. fehlerhaften) Konfiguration nun auch wirklich normal durchführen lassen. (Und nicht nur im 10s Stakato)

Es ist also auch wohl ein sich lohnender Mehraufwand. (Sowohl am Programm, als auch an mir! :-))

Gruß, Stefan