[FHEM-devel] FHEM-Multithreaded: Sinn&Unsinn&Generelle Machbarkeit
Axel
dieser Thread "schwapp" aus der Users-Group herüber....
Ich möchte mal eurer Meinungen und
ev. schon ein paar technische Ansätze zum Multithreading [MT] in FHEM
"einsammlen"....
Das soll erstmal "kein Antrag" auf Einführung von MT in fhem sein.
1. Schritt: Wie stelle ich fest ob "mein" Perl Multithreaded ist:
>perl -V
osname=darwin, osvers=10.0, archname=darwin-thread-multi-2level
Perl-Minus-Grosse V liefert:
osname=darwin -> Perl aufm Mac
osvers=10.0 -> OS Version 10 alias Mac OS X
archname=darwin-thread-multi-2level -> Perl ist Multithread
kompliliert
Also auf dem Rechner könnte FHEM Multithreaded laufen ;-))
Und hier auch (Sheeva):
osname=linux, osvers=2.6.28.7.1, archname=arm-linux-gnueabi-thread-
multi
Warum...
Ich nehme mal das Twitter-Command als Beispiel.
Kurz die Funktionsweise:
Das Twittern erfolgr per Perl-LWP.
LWP-Timeout ist auf 5 sec "gestellt", ein 3 sec Timeout war "zu kurz".
Der Return-Value des Twitter-Updates wird ausgewertet und fürs Error-
handling genutzt.
Nach 5 Fehlversuchen in Folge wird das Twitter-Commando deaktiviert.
In der Zeit des Twitter-Updates ist fhem nun komplett blokiert.
Das soll nun asynchron laufen oder "nicht blockierend"...z.B. per
Thread
Weitere "Kandidaten": PachLog, RRDLog.. ?????
und zwar so:
twitter "<MSG>" -> ein paar Prüfungen -> absetzten des perl-lwp-
aufrufs per thread -> "Rückkehr zu fhem"
Anschließend "irgendwann später" einsammeln des Return-Values vom perl-
lwp-aufruf.
fhem.pl
use threads;
use threads::shared;
$thr = threads->new(\&twitter); # Spawn the thread
$thr->detach; # Now we officially don't care any more
Das habe ich in in der Form schonmal ausprobiert.
Die twiiter-Config Daten sind in %data gespeichert.
Im thread "new(\&twitter)" war lesender Zugriff möglich; kein
schreibender Zugriff.
Und...was meint ihr dazu ???
Quelle:
http://perldoc.perl.org/threads.html
http://perldoc.perl.org/threads/shared.html
http://www.mathematik.uni-ulm.de/help/perl5/doc/perlthrtut.html
Schöne Grüsse
Axel
--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM developers beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-de...@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-develope...@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-developers?hl=de, um weitere Optionen zu erhalten.
nobody
ich bin vollständig GEGEN mutlithreading.
Grund:
Es wird auf kaum einer Embedded-Plattform unterstützt.
Abhilfe:
Mulit-Prozessing, wie es schon in PGM2 und auch in der neuen Beta des
FHEM-Renderers eingesetzt wird.
Dadurch kann FHEM in Ruhe machen was es will, während im anderen
Prozess Grafiken gebaut werden, oder was auch immer.
Und ist Programm-Technisch noch viel einfacher, als Threading. Darüber
hinaus läuft das auf JEDER Plattform.
Gruß,
O.
> Schöne Grüsse
>
> Axel
>
> --
> Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM developers beigetreten sind.
> Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-de...@googlegroups.com.
> Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-develope...@googlegroups.com.
Rudolf Koenig
> Grund:
> Es wird auf kaum einer Embedded-Plattform unterstützt.
gesammelt habe: Programmieren und Fehlersuche ist aufwendig, und viele
"third-party" Komponenten haben Probleme damit.
> Mulit-Prozessing, wie es schon in PGM2 und auch in der neuen Beta des
> FHEM-Renderers eingesetzt wird.
Ergebnisse ueber die gewoehnlichen fhem Kommandos (d.h. TCP/IP) zurueckmelden.
Das ist schneller als viele es annehmen. Sinnvollerweise sollten wir ein
Verfahren beschliessen, und Hilfsfunktionen/Doku dafuer fertigmachen.
Ich habe nach diesem Muster ein 21_OWTEMP.pm gebaut, OWFS hat aber prinzipiell
Probleme mit parallelen Zugriff (wenn ich mich richtig erinnere).
Abgesehen davon wuesste ich schon gerne, ob/wie man in perl threading
verwendet :). Oder wie Axel es schon wissen wollte: wie modifiziert man globale
Variablen aus einem zweiten Thread.
Kai 'wusel' Siering
> Ich möchte mal eurer Meinungen und
> ev. schon ein paar technische Ansätze zum Multithreading [MT] in FHEM
> "einsammlen"....
> Das soll erstmal "kein Antrag" auf Einführung von MT in fhem sein.
ich halte nicht viel von Multithreading, grade im Zusammenspiel mit externen
Komponenten. Falls FHEM mal einen Datensammlungs-Thread, einen telnet-/Kommando-
Thread und ggf. einen Logging-Thread bekäme, würde ich das für sinnvoll er-
achten, denn daß ein beliebiges Vorkommnis den gesamten Prozeß aufhält, wird
sicher zunehmend zu einem Problem werden in der Zuverlässigkeit.
Externe Dienste wie twitter, pachube(sp?), ... hingegen würde ich durch von
FHEM angestoßene separate Prozesse bedienen wollen. Hierfür wäre ein Rahmen
zu schaffen, der die Rückgabe von Werten (Erfolg/Mißerfolg, Tokens, ...) an
FHEM ermöglicht.
Dazu gab's schon mal außerhalb der Liste Ansätze, ggf. wäre das mal breiter
zu diskutieren.
Ciao,
kai
Axel
Weiss jemand wie man solche Variablen shared ???
[fhem.pl]
use vars qw(%data);
Schöne Grüße
Axel
Dr. Boris Neubert
weil Multithreading auch noch auf der Liste steht hier eine
Zusammenfassung der Ergebnisse in diesem Thread zur Auffrischung der
Erinnerung:
Anlass der Diskussion:
- Laengere Verarbeitungsprozesse in einzelnen Modulen (z.B. aufgrund von
Netzwerklatenzen oder toten Geraeten) halten fhem komplett an und
verhindern die Verarbeitung von Events. Frage: ist Multithreading
hierfuer eine Loesung?
Argumente gegen Multithreading:
- Wird praktisch auf keiner kleinen Plattform unterstuetzt.
- Negative Erfahrungen (z.B. Probleme bei vielen 3rd-party-Komponenten)
- Kaum Programmiererfahrung mit Multithreading in Perl.
Alternative:
- Multiprocessing
In diesem Modell (sofern erforderlich) muessen die Hintergrund-Prozesse
Ergebnisse ueber die gewoehnlichen fhem-Kommandos (d.h. TCP/IP)
zurueckmelden. Das ist schneller als viele es annehmen.
Muster: 21_OWTEMP.pm
Naechster Schritt:
- Verfahren beschliessen / dokumentieren.
Wie soll es aussehen?
Gruesse,
Boris
Dr. Boris Neubert
Rudolf Koenig schrieb:
> In diesem Modell (sofern erforderlich) muessen die Hintergrund-Prozesse
> Ergebnisse ueber die gewoehnlichen fhem Kommandos (d.h. TCP/IP) zurueckmelden.
> Das ist schneller als viele es annehmen. Sinnvollerweise sollten wir ein
> Verfahren beschliessen, und Hilfsfunktionen/Doku dafuer fertigmachen.
>
> Ich habe nach diesem Muster ein 21_OWTEMP.pm gebaut, OWFS hat aber prinzipiell
> Probleme mit parallelen Zugriff (wenn ich mich richtig erinnere).
ist das eingecheckt? Ich kann den o.g. Mechanismus nicht sehen.
Gruesse,
Boris
Rudolf Koenig
Nein, es war nicht. Ich habe es jetzt unter contrib/21_OWTEMP.pm.fork
eingecheckt.
Dr. Boris Neubert
> Wie soll es aussehen?
Ich habe unter
http://fhemwiki.de/index.php/DevelopmentGuidelines#Aktualisierung_der_Readings
Dokumentation und Fragen
- zur Polling-Infrastruktur und
- zum Multiprocessing
aufgeschrieben.
Das Multiprocessing ist eine leicht abgewandelte Variante des Kodes in
contrib\21_OWTEMP.pm.fork von Rudi.
Neben einer kritischen Würdigung der Verfahren steht m.E. auch die
Überlegung an, ob man Multiprocessing und Polling-Infrastruktur in
Service-Module auslagert, um Koderedundanzen zu vermeiden.
Grüße,
Boris
Rudolf Koenig
> �berlegung an, ob man Multiprocessing und Polling-Infrastruktur in
> Service-Module auslagert, um Koderedundanzen zu vermeiden.
Natuerlich soll es ausgelagert werden. Aber ich finde das Ganze nur dann
sinnvoll, falls es wenigstens mit einem Modul wirklich eingesetzt wird. Bei
dem OW scheint es ja nicht zu klappen, da (wenn ich mich recht erinnere) das
verwendete OW Bibliothek selbst nicht multithread faehig ist.
Dr. Boris Neubert
> Natuerlich soll es ausgelagert werden. Aber ich finde das Ganze nur dann
> sinnvoll, falls es wenigstens mit einem Modul wirklich eingesetzt wird. Bei
> dem OW scheint es ja nicht zu klappen, da (wenn ich mich recht erinnere) das
> verwendete OW Bibliothek selbst nicht multithread faehig ist.
Oh. Ich hatte es so verstanden, dass 21_OWTEMP.pm.fork funktionieren
wuerde (kann es selbst nicht testen). Wir koennten aber ganz pragmatisch
vorgehen und die Entwicklung des Multiprocessing-Moduls zurueckstellen,
bis ein Modul es braucht und es mit der im Wiki dokumentierten Variante
funktioniert.
Die Polling-Infrastruktur wird aber definitiv gebraucht. Wir koennten
das so regeln, dass die fhem-Infrastruktur nach dem define prueft, ob
ein Internal "polling" gesetzt ist, und dann automatisch ein Timer
gestartet wird, der mit dem im Internal "polling" vorgebenen Intervall
eine neu einzufuehrende PollFn im Modul aufruft. Beim delete wird der
Timer dann wieder entfernt.
Gruesse,
Boris
Olaf Droegehorn
das klingt alles recht gut.
Der FHEM_RENDERER verwendet multi_processing, und das Polling habe ich
selbst dadurch realisiert, dass beim einschalten des Renderers der Timer
gesetzt wird, und danach die GETFn aufgerufen wird, und der Timer darin
neu gesetzt wird.
BTW: In welchem Wiki wird das denn beschrieben ? Hab ins FHEMWIKI
geschaut, aber nicht gefunden.
Wenn wir daf�r eine allgemeine Struktur und FHEM_Support bekommen, dann
w�re ich recht froh.
Bzgl. Multiprocessing: wie genau wollt ihr das denn auslagern ?
Danke,
Gru�,
Olaf
Dr. Boris Neubert schrieb:
--
------------------------------------------------------------------------
Dr. Olaf Droegehorn
General Manager Tel. : +49-561-82020-410
DHS - Computertechnik GmbH Fax. : +49-561-82020-399
Carlsdorfer Stra�e 3 E-Mail: O.Droe...@dhs-computertechnik.de
WEB: www.dhs-computertechnik.de
D-34128 Kassel
------------------------------------------------------------------------
Dr. Boris Neubert
Olaf Droegehorn schrieb:
> Der FHEM_RENDERER verwendet multi_processing, und das Polling habe
> ich selbst dadurch realisiert, dass beim einschalten des Renderers
> der Timer gesetzt wird, und danach die GETFn aufgerufen wird, und der
> Timer darin neu gesetzt wird.
ja, das ist aktuell wohl das Standardvorgehen, das alle nutzen.
> BTW: In welchem Wiki wird das denn beschrieben ? Hab ins FHEMWIKI
> geschaut, aber nicht gefunden.
hier:
http://fhemwiki.de/index.php/DevelopmentGuidelines#Aktualisierung_der_Readings
> Wenn wir dafür eine allgemeine Struktur und FHEM_Support bekommen,
> dann wäre ich recht froh.
Ich wuerde mich freuen, wenn wir noch weitere Diskussionsbeitraege
hoeren. Sofern sich dann eine tragfaehige Loesung herauskristalliert,
wuerde ich diese zur Abstimmung stellen.
> Bzgl. Multiprocessing: wie genau wollt ihr das denn auslagern ?
Multiprocessing ist eine relativ junge Technik fuer fhem und es gibt
wohl noch recht wenig Erfahrungen dazu.
Grob koennte ich es mir wie folgt vorstellen:
- Es gibt ein synchrones und ein asynchrones Get als Bestandteil der
fhem-Infrastruktur.
- Welches Get verwendet wird, wird im Modul definiert (ggf. abhaengig
vom Reading).
- Beide Gets greifen auf die jeweilige modulspezifische Funktion GetRaw
zu, die die Daten vom Geraet abholt.
- Die Aufrufmechanismen sind:
synchrones Get:
GetRaw
Daten in das Readings-Hash fuellen und Notifys ausloesen
asynchrones Get:
schon geforkt? Dann Abbruch.
Fork
Vaterprozess:
Unverzueglich zurueckkehren
Kindprozess:
GetRaw
Daten ueber Socket an den Vaterprozess uebermitteln
Vaterprozess fuellt Daten in das Readings-Hash und
loest Notifys aus
Der Perl-Code unter obigem Link muesste dazu entsprechend in fhem.pl
gekapselt werden.
Viele Gruesse,
Boris
Olaf Droegehorn
das klingt gut, mit einer Ausnahme:
Da virtuelle Module (denen also keine echten Devices zugrunde liegen)
kein GetRaw brauchen, sondern irgendwas anderes in der Zeit treiben (wie
beim Renderer da malen von Grafiken) sollte statt GetRaw eine
allgemeinere Funktion stehen, in der dann das spezielle Verhalten
programmiert wird.
Ein GetRaw klingt automatisch nach Sensor-Werten, was es ja nicht immer
sein m�ssen.
Und zur�ckgeben m�ssen die Kinder auch nur was, wenn der Vater dies
irgendwo hin schreiben will.
Wenn Logs/Files direkt auf die Platte generiert werden sollte da
h�chstens eine Benachrichtigung geschickt werden, falls �berhaupt. Also
optional an der Stelle.
Desweiteren sollte es dann Konfig-Attribute geben, in denen
MultiProcessing an-/abgeschaltet werden kann, und Intervalle f�r Polling
definiert weden k�nnen.
Ebenfalls sollte Polling abschaltbar sein, falls man selber lieber
direkt abholen mag (so hab ich es im Renderer).
Just my 2 Cents.
Olaf
> hier:
> http://fhemwiki.de/index.php/DevelopmentGuidelines#Aktualisierung_der_Readings
--