Bei richtigen Threads reicht das nicht.

Threads arbeiten ja in gewisser weise Parallel und da die variablen global sind kann es rein theoretisch sein das du ein Match bei einer Regex hast und diese $1, $2, $3 etc. setzt und dann direkt danach ein anderer Thread seine arbeit verichtet und dort eine neue Regex ausgeführt wird und $1, $2, ... neu setzt.

Von daher wenn du soetwas hast musst du die match variablen vorher locken.

Allerdiengs ist das jetzt allgemein für Threads gesehen. Ich weiß nicht wie das genau bei Perl mit seinem ithreads ist.

Aber unabhängig mal ganz vom Thema abgesehen würde ich auch keinem Threads in perl empfehlen.

Für Multitasking gab es ja ursprünglich forken. Problem mit Forken ist das bei einem Fork zwei komplett voneinander unabhängige Prozese entstehen. Problem stellt auch die Kommunikation zwischen beiden dar, vorallem kosten sie auch viel speicher und ich sag mal einfach sie sind nicht sehr schnell, vorallem wenn man viele auf einmal haben möchte.

Der Sinn hinter Threads war es dieses manko zu beheben. Leichtgewichtigt zu sein, weniger Speicher zu haben, performanter zu sein und dadurch das auch Daten zwischen den Threads ausgetauscht werden bzw besser gesagt dadurch das beide auf den gleichen Daten zuzugreifen die Kommunikation zu vereinfachen.

Keins von den Zielen wird durch die ithread Implementierung in Perl erreicht. Dadurch das ein kompletter Interpreter in jedem Thread läuft sind die Perl Threads schwerfälliger als das Forken, sie sind langsamer und verbrauchen sogar noch mehr Speicher als wenn man forkt. Vorallem mit neuen Technik wie Copy-on-Write sind selbst neue Prozesse im OS nicht mehr so aufwendig wie früher. Und einen echten austausch zwischen den Threads hat man auch nicht. Man muss Variablen vorher explizit mackieren und dann gibt es eine hand voll probleme mit objekte da sie nicht zwischen Threads getauscht werden können und auch mit Datenstrukturen und deren Locking. Insgesamt ist das eingebaute Threading meiner Ansicht nach ziemliche verschwendung in Perl und würde das keinem empfehlen.

Wenn dann würde ich lieber auf eine Eventlibrary aufsetzen. Am besten gleich eine Abstraktion wie AnyEvent oder POE. Vorallem da du bei einer Eventlibrary keine "echte" Parallelität hast würde das vorgehen an dieser stelle keine Probleme machen und du rennst auch nicht in die Probleme mit Threads von wegen Threadsicher etc.

Auch sind EventLibrarys Platformunabhängiger als Forken oder Threading. Vorallem halte ich das Programmierung mit Threads auch nicht gerade sehr viel einfacher.

Ansonsten für eine weitere Thread implementierung kann man sich mal Coro anschauen. Weiterhin gibt es auch Coro::AnyEvent was dann die Coro Threads in einer Eventschleife einbettet.

Ansonsten sind Coro Kooperative Threads. Daher auch hier hat man keine "echte" Parallelität (naja was ist shcon echt?). Aber dafür hat man auch nicht die Probleme mit der Threadsicherheit. Daher man hat auch mit Coro nicht die Probleme mit $1, $2, ...

Allerdiengs ist Multitasking und deren Programmierung kein Spezialthema von mir und mache ich äußert selten, von daher alles ohne Garantie. ;)

EDIT: Link korregiert
Last edited: 2010-01-04 20:12:56 +0100 (CET)