Modul: multitask braucht man das?

[Sr4l]

Kann ich trozdem auch weiterhin bei den Pythonmitgeliferten Threading Varianten bleiben oder was bringt das Modul mehr?

http://o2s.csail.mit.edu/o2s-wiki/multitask

[Leonidas]

Es erinnert mich von der Einfachheit der Nutzung an die Ruby-Threads, die ja auch Soft-Threads sind. Es hat eine nette API. Letztendlich hast du damit Gleichzeitigkeit, ohne Threads zu nutzen.

[lunar]

Es erinnert mich von der Einfachheit der Nutzung an die Ruby-Threads, die ja auch Soft-Threads sind. Es hat eine nette API. Letztendlich hast du damit Gleichzeitigkeit, ohne Threads zu nutzen.

Gibt es da irgendeinen essentiellen, wichtigen Vorteil?

[veers]

Es erinnert mich von der Einfachheit der Nutzung an die Ruby-Threads, die ja auch Soft-Threads sind. Es hat eine nette API. Letztendlich hast du damit Gleichzeitigkeit, ohne Threads zu nutzen.

Gibt es da irgendeinen essentiellen, wichtigen Vorteil?

Weniger Problem mit der Nebenläufigkeit was zu geringerer Komplexität, weniger Bugs und vereinfachtem Debugen führt. Ich muss zwar zugeben dass ich noch nie eine Python Awendung mit mehreren Threads debugt habe aber ich denke es wird ähnlich mühsam sein wie in anderen Sprachen. Abgesehen davon ist es in einigen Fällen sogar schneller als echte Threads da der aufwand einen Thread zu erstellen relativ gross ist (Ja, kann mit Pooling gesenkt werden).

[BlackJack]

Ich kenne diese Implementierung jetzt nicht, aber meistens wird bei Coroutinen angeführt, dass der Overhead geringer ist als bei Threads. Sie laufen komplett im Userspace, es gibt also kein "(kleines) Taskswitching", und man kann im allgemeinen beliebig viele davon starten. Wenn man zum Beispiel eine Ameisenkolonie mit 3000 Computerspielern simulieren will, dann sollte man besser keine 3000 Threads starten. Falls das Betriebssystem das überhaupt mitmacht.

[lunar]

Abgesehen davon ist es in einigen Fällen sogar schneller als echte Threads da der aufwand einen Thread zu erstellen relativ gross ist (Ja, kann mit Pooling gesenkt werden).

Ich habe keine Ahnung von Windows, allerdings glaube ich nicht, dass der Aufwand zum Erzeugen von Threads unter Linux sehr, sehr groß ist. Immerhin erzeugt fork() unter Unix sehr effizient neue Prozesse und auf Kernelebene ist ein Thread auch nur wenig anders als ein Prozess. Der einzige echte Nachteil wären doch, so wie ich das sehe, höchstens Kontextwechsel.

Außerdem hängt doch auch viel an der Scheduler-Implementierung. Ich bezweifle, dass der Scheduler dieses Moduls wesentlich effizienter ist als der Scheduler des Linux-Kernels.

@Blackjack: Naja, ob ich dafür 3000 Coroutinen laufen lassen würde...

[BlackJack]

Coroutinen haben im Grunde keinen Scheduler bzw. in der Regel einen sehr einfachen. Die einzelnen Routinen stossen den Wechsel zu einer anderen Routine ja selbst an.

Warum keine 3000 Coroutinen? Der grosse Vorteil ist, dass jede Ameise (oder was immer man dort auch sonst Simulieren möchte) als eigenständiges kleines AI-Programm laufen kann, das beliebig komplex ist. Bei der Alternative, in der Hauptschleife immer auf allen 3000 Individuen eine Funktion aufzurufen, die einen kleinen Schritt macht, sieht man im Quelltext von den Individuen, den für das einzelne Individuum ja eigentlich linearen Programmablauf nicht so schön.

[veers]

Abgesehen davon ist es in einigen Fällen sogar schneller als echte Threads da der aufwand einen Thread zu erstellen relativ gross ist (Ja, kann mit Pooling gesenkt werden).

Ich habe keine Ahnung von Windows, allerdings glaube ich nicht, dass der Aufwand zum Erzeugen von Threads unter Linux sehr, sehr groß ist. Immerhin erzeugt fork() unter Unix sehr effizient neue Prozesse und auf Kernelebene ist ein Thread auch nur wenig anders als ein Prozess. Der einzige echte Nachteil wären doch, so wie ich das sehe, höchstens Kontextwechsel.

Das ist sicherlich so. Darum habe ich auch gesagt in einigen Fällen. Soweit ich weis verwendet Eve Online (Ein MMORPG), unteranderem deshalb Stackless Python/Tasklets. Das ist aber sicherlich ein extrem Beispiel