MemoryLeaks mit s := I.ToString

[Kraisel]

Für den Thread hast Du völlig recht. Da habe ich mich vielleicht nicht klar genug ausgedrückt, denn ich wollte sicher nicht anregen, dass man Suspend benutzen soll. Ich habe lediglich versucht, die Analogie zum Fiber hergestellt, denn da besteht leider immer das Problem, dass das Ende der Methoden in denen umgeschaltet wird niemals aufgerufen werden, wenn der Fiber gerade beendet wird. Er kann sich leider auch nicht selber beenden. Wenn er das tut, indem er einfach die Methode verlässt, wird der Thread, indem er läuft, beendet, und alle anderen Fiber stehen unkontrolliert in ihrer letzten Umschaltung. Und das ist wohl der großer Nachteil bei Fiber. Man muss alle Spielregeln beachten und genau wissen, was man da darf und was nicht. Wenn man das ignoriert, müllt man sich langfristig den Speicher zu. Ansonsten sind Fiber aber eben wesentlich schneller als Threads. Man kann leider nicht alles haben.

Vielen Dank für alle Hinweise.

[himitsu]

OK, der Thread des Fiber darf nicht vom Fiber beendet werden, aber auch der Fiber muß sich selber beenden, indem er selber am Ende eine bestimmte Funktion aufruft.
Von außen darf auch ein Fiber nicht einfach so unkontrolliert angehalten/beendet werden, damit er nicht in einem "ungünstigen" Zustand stehen bleibt.

Egal ob Thread oder Fiber, sobald etwas globales verwendet wird, muß man aufpassen, daß dieses im Moment des Anhaltens nicht benutzt wird,
außer es gibt atomare Locking-/Zugriffsfunktionen und man könnte die Locks von außen freigeben.

[BUG]

Ich hab irgendwie den Eindruck, ihr wisst beide worum es geht und was man Grundsätzlich beachten muss, und redet jetzt nur noch ein bisschen aneinander vorbei. Für Leute ohne Erfahrung mit Nebenläufigkeit ist das sicher interessant, aber ansonsten nicht sonderlich produktiv

[Luckie]

Hey, lass uns doch auch mal den Coolen raushängen. Und auch das Nebeneinadervorbeireden birgt ja noch zusätzliches Wissen. Den Beitrag über die Vor- und Nachteile und wann was besser geeignet ist, fand ich interessant.

[QuickAndDirty]

Ich wusste nicht mal das es Fiber gibt.

Ab wievielen "gleichzeitigen" prozessen lohnt sich jetzt Fiber?

Ich meine, dass die neuen Indy componenten ja auch von einem Thread pro connection geäandert wurden, so dass es da jetzt
einen Context pro Connection und mehrere Contexte in einem Thread gibt.

Mehrere Contexte pro Thread ist ein Indy-Context schon ein Fiber?

Also ab wievielen Verbindungen ist ein Fiber pro Verbindung besser als ein Thread?

[Kraisel]

Schön, dass es doch noch jemand gibt, der sich für dieses Thema interessiert. Aber es ist richtig, dass im Grunde fast alles gesagt ist, und mit dem ursprünglichen Thema nichts mehr zu tun hat. Über Threads, Fiber und Co. könnte man natürlich stundenlang schreiben.

Aber noch soviel zu den Fragen:

Die Indy-Komponenten kenne ich nicht.

Microsoft gibt an, dass maximal 16 Threads pro CPU laufen sollten, und auch nur dann, wenn alle die meiste Zeit auf etwas warten. Die nackte schnellstmögliche Umschaltung von vier Threads dauert auf meinem PC 2.0..5.0 us je Umschaltung. Wichtig ist auch noch zu wissen, dass ein Thread 5..20ms braucht, um zu starten. Wenn der Thread also nicht schon da ist und läuft, und man glaubt, mal eben einen anonymen Thread parallel laufen zu lassen, wird bitter enttäuscht werden. Alles wird deutlich langsamer als ohne Thread.

Der Fiber ist in Delphi leider ein Windows-Konstrukt und m.E. nicht für Mac oder NewGeneration-Compiler verfügbar. Wie lange er also noch gepflegt wird, weiß leider niemand. Also auch hier Vorsicht bei der Benutzung für neue Anlagen. Aber wenn man ihn benutzt, wird man mit atemberaubender Geschwindigkeit von meist über 100 mal schneller belohnt. Die Nachteile hatte ich ja bereits beschrieben.

[taveuni]

Zitat von Kraisel:

Microsoft gibt an, dass maximal 16 Threads pro CPU laufen sollten, und auch nur dann, wenn alle die meiste Zeit auf etwas warten.

Wo? Diese absolute Aussage steht so irgendwo? Kannst Du mir den Link posten?