Polling versus Ereignissteuerung

[Gerhard Landeck]

Hallo,

keine Java-spezifische Frage, sondern eher was Allgemeines:

jemand hat behauptet, Ereignissteuerung sei nichts anderes als
verstecktes Polling. Wikipedia sagt dazu, dass Ereignissteuerung
entweder durch Hardware-Interrupts oder durch Callback-Mechanismen
realisiert wird. Da ist doch kein verstecktes Polling drin, oder?

Gruß, Gerhard
Bei Fehlern im Code ist das Chaos programmiert.
Irgendeine Software Engineering Publikation

[Florian Weimer]

Post by Gerhard Landeck
jemand hat behauptet, Ereignissteuerung sei nichts anderes als
verstecktes Polling. Wikipedia sagt dazu, dass Ereignissteuerung
entweder durch Hardware-Interrupts oder durch Callback-Mechanismen
realisiert wird. Da ist doch kein verstecktes Polling drin, oder?

Es gibt Implementierungen, die die Probleme von Polling nicht
vollständig vermeiden. Vielleicht war das gemeint?

[Gerhard Landeck]

Post by Florian Weimer

Post by Gerhard Landeck
jemand hat behauptet, Ereignissteuerung sei nichts anderes als
verstecktes Polling. Wikipedia sagt dazu, dass Ereignissteuerung
entweder durch Hardware-Interrupts oder durch Callback-Mechanismen
realisiert wird. Da ist doch kein verstecktes Polling drin, oder?

Es gibt Implementierungen, die die Probleme von Polling nicht
vollständig vermeiden. Vielleicht war das gemeint?

Hmm, nein, es ging eher um die Häufigkeit / Regelmäßigkeit von
Prozessoraktivitäten und in diesem Zusammenhang um Energieverbrauch.

Gruß, Gerhard
Bei Fehlern im Code ist das Chaos programmiert.
Irgendeine Software Engineering Publikation

[Florian Weimer]

Post by Gerhard Landeck

Post by Florian Weimer

Post by Gerhard Landeck
jemand hat behauptet, Ereignissteuerung sei nichts anderes als
verstecktes Polling. Wikipedia sagt dazu, dass Ereignissteuerung
entweder durch Hardware-Interrupts oder durch Callback-Mechanismen
realisiert wird. Da ist doch kein verstecktes Polling drin, oder?

Es gibt Implementierungen, die die Probleme von Polling nicht
vollständig vermeiden. Vielleicht war das gemeint?

Hmm, nein, es ging eher um die Häufigkeit / Regelmäßigkeit von
Prozessoraktivitäten und in diesem Zusammenhang um Energieverbrauch.

Man kann das sicherlich so oder so implementieren. Wenn man z.B. keine
Prioritätswarteschlange baut, sondern stupide alle 100 ms schaut, ob
ein Timeout abgelaufen ist, hat man Ereignissteuerung mit verstecktem
Polling. Es gab sehr lange Zeit auch nur wenig Systeme, die das
grundsätzlich anders machten (d.h. auf unterster Ebene tatsächlich
ohne periodischen Timer-Interrupt auskamen).

[Marcel Mueller]

Post by Gerhard Landeck
jemand hat behauptet, Ereignissteuerung sei nichts anderes als
verstecktes Polling. Wikipedia sagt dazu, dass Ereignissteuerung
entweder durch Hardware-Interrupts oder durch Callback-Mechanismen
realisiert wird. Da ist doch kein verstecktes Polling drin, oder?

Nein, wenn es korrekt implementiert ist, benötigt man kein Polling.
Es gibt aber immer mal wieder Verfahren, die doch immer mal wieder zu
unnötigem Aufwachen von Threads führen. Das gilt sowohl die
Hardware-Ebene, z.B. bei Shared Interrupts, als auch für die Software,
zum Beispiel bei Bedingungsvariablem. Solche "Fehlzündungen" in Kauf zu
nehmen, ist in Summe oft effizienter, als es akkurat zu lösen. Manchmal
nimmt man es gar explizit in Kauf. So sind z.B. die Schnellen Spin-Locks
nichts anderes als Polling. Und auch die CAS-Schleifen für bei schnellen
Lock-Free Algorithmen sind letztlich nichts anderes.

Und auch der Übergang von Polling zu Events ist nicht digital. Wenn
beispielsweise in der Polling-Schleife ein sleep(0) drin ist, kann
selbige möglicherweise ohne signifikante Beeinträchtigung anderer
Software ihre Runden drehen. Wenn es nach ein paar Runden auf sleep(1)
wechselt, kann man auch die Auswirkungen auf den Energieverbrauch
weitgehend vermeiden.

Post by Gerhard Landeck
Gruß, Gerhard
Bei Fehlern im Code ist das Chaos programmiert.
Irgendeine Software Engineering Publikation

Ja und undefiniertes Verhalten, schließt den Fall, dass es geht auch mit
ein. ;-)


Marcel

[Gerhard Landeck]

On Thu, 15 Oct 2015 08:32:40 +0200, Marcel Mueller

Post by Marcel Mueller

Post by Gerhard Landeck
jemand hat behauptet, Ereignissteuerung sei nichts anderes als
verstecktes Polling. Wikipedia sagt dazu, dass Ereignissteuerung
entweder durch Hardware-Interrupts oder durch Callback-Mechanismen
realisiert wird. Da ist doch kein verstecktes Polling drin, oder?

Nein, wenn es korrekt implementiert ist, benötigt man kein Polling.

Aha.

Post by Marcel Mueller
Es gibt aber immer mal wieder Verfahren, die doch immer mal wieder zu
unnötigem Aufwachen von Threads führen. Das gilt sowohl die
Hardware-Ebene, z.B. bei Shared Interrupts, als auch für die Software,
zum Beispiel bei Bedingungsvariablem. Solche "Fehlzündungen" in Kauf zu
nehmen, ist in Summe oft effizienter, als es akkurat zu lösen. Manchmal
nimmt man es gar explizit in Kauf. So sind z.B. die Schnellen Spin-Locks
nichts anderes als Polling. Und auch die CAS-Schleifen für bei schnellen
Lock-Free Algorithmen sind letztlich nichts anderes.

OK, Spin-Lock und CAS sagt mir nichts.

Post by Marcel Mueller
Und auch der Übergang von Polling zu Events ist nicht digital. Wenn
beispielsweise in der Polling-Schleife ein sleep(0) drin ist, kann
selbige möglicherweise ohne signifikante Beeinträchtigung anderer
Software ihre Runden drehen. Wenn es nach ein paar Runden auf sleep(1)
wechselt, kann man auch die Auswirkungen auf den Energieverbrauch
weitgehend vermeiden.

Energieverbrauch ist das Stichwort.

Beispiel Xeyes, bekannt von Fenstermanagern unixoider Systeme.
Für die, die es nicht kennen: zwei Augen, deren Pupillen immer dem
Cursor folgen, also ein recht nützliches Programm, das jeder unbedingt
haben sollte.

1.(naive?) Implementierung: Xeyes fragt -zig mal pro Sekunde die
Cursorposition ab, also auch, wenn der Cursor sich nicht bewegt, wird
der Prozessor aktiv. Klassisches Polling.

2. Implementierung (Ereignisgesteuert): Xeyes registriert sich beim BS
als "Interessent" für Cursorpositionen. Ändert sich diese, wird Xeyes
benachrichtigt.
Da ist doch kein verstecktes Polling drin?

Post by Marcel Mueller

Post by Gerhard Landeck
Gruß, Gerhard
Bei Fehlern im Code ist das Chaos programmiert.
Irgendeine Software Engineering Publikation

Ja und undefiniertes Verhalten, schließt den Fall, dass es geht auch mit
ein. ;-)

Aber auch nicht immer, oder? ;-)

[Marcel Mueller]

Post by Gerhard Landeck
2. Implementierung (Ereignisgesteuert): Xeyes registriert sich beim BS
als "Interessent" für Cursorpositionen. Ändert sich diese, wird Xeyes
benachrichtigt.
Da ist doch kein verstecktes Polling drin?

Xeyes verursacht AFAIK keine wahrnehmbare CPU Last. Und das nicht erst
seit neuestem.

Den Takt gibt letztlich der Maustreiber vor und der hängt bei USB am
USB-Controller-Interrupt, der wiederum durch Polling mit 1kHz die Maus
nach neuen Koordinaten fragt. Letzters Polling ist Teil der
USB-Spezifikation und damit unvermeidbar. USB-Devices können sich nicht
unaufgefordert am Bus melden. Die CPU ist aber unbeteiligt.

Post by Gerhard Landeck

Post by Marcel Mueller
Ja und undefiniertes Verhalten, schließt den Fall, dass es geht auch mit
ein. ;-)

Aber auch nicht immer, oder? ;-)

Doch schon, aber er /tritt/ nicht immer ein. Selten ist das dennoch
nicht. Ich habe schon genug Programmcode gesehen, der nur zufällig
funktioniert. Üblicherweise natürlich mit recht hoher
Wahrscheinlichkeit. Race-Conditions sind eine der beliebtesten
Stolperfallen dabei.


Marcel

[Gerhard Landeck]

On Thu, 15 Oct 2015 18:50:48 +0200, Marcel Mueller

Post by Marcel Mueller

Post by Gerhard Landeck
2. Implementierung (Ereignisgesteuert): Xeyes registriert sich beim BS
als "Interessent" für Cursorpositionen. Ändert sich diese, wird Xeyes
benachrichtigt.
Da ist doch kein verstecktes Polling drin?

Xeyes verursacht AFAIK keine wahrnehmbare CPU Last. Und das nicht erst
seit neuestem.

Es geht nicht um "wahrnehmbare " CPU-Last. Und auch nicht um Xeyes.
Das war nur ein Beispiel.

Post by Marcel Mueller
Den Takt gibt letztlich der Maustreiber vor und der hängt bei USB am
USB-Controller-Interrupt, der wiederum durch Polling mit 1kHz die Maus
nach neuen Koordinaten fragt. Letzters Polling ist Teil der
USB-Spezifikation und damit unvermeidbar. USB-Devices können sich nicht
unaufgefordert am Bus melden. Die CPU ist aber unbeteiligt.

Sicher, aber ich kann mir nicht vorstellen, dass ein Programm wie
(z.B.) Xeyes direkt die Hardware fragt, wo der Cursor steht. Die fragt
doch das Betriebssystem.

Bevor ich mir die Finger wund schreibe, hier mal der Link, wo das
beschrieben ist.

http://arstechnica.com/apple/2013/10/os-x-10-9/14/


Primär denke ich, geht es mehr um Callback-Methoden.

[Marcel Mueller]

Post by Gerhard Landeck
Sicher, aber ich kann mir nicht vorstellen, dass ein Programm wie
(z.B.) Xeyes direkt die Hardware fragt, wo der Cursor steht. Die fragt
doch das Betriebssystem.

Natürlich, aber das ändert nichts. Das Programm bekommt halt eine
Message, nachdem die Maus geschubst wurde.

Post by Gerhard Landeck
Bevor ich mir die Finger wund schreibe, hier mal der Link, wo das
beschrieben ist.
http://arstechnica.com/apple/2013/10/os-x-10-9/14/

Sorry, das ist mir zu lange. Nachdem er nach eine halben Seite immer
noch nicht zur Sache kam, habe ich aufgegeben. Vielleicht habe ich aber
auch nichts verstanden, weil das alles Apple-spezifischer Kram ist.

Post by Gerhard Landeck
Primär denke ich, geht es mehr um Callback-Methoden.

Üblicherweise verwenden GUI Anwendungen Message-Queues.
Für jeden Pups einen Callback zu registrieren ist dann doch etwas aufwändig.

Die Message-Queues werden natürlich in einer (fast) Endlosschleife
gelesen. Aber die Funktion zum Lesen der nächsten Message landet über
kurz oder lange im Betriebssystemkern, wo sie sämtliche CPU-Ressourcen
abgibt, solange bis tatsächlich eine Message verfügbar ist.

Natürlich gibt es immer mal wieder einen Programmierer, der in einer
echten Endlosschleife irgendwelche nichblockierenden API-Funktionen
aufruft, oder der mit ständigen Timer-Events etwas subtiler seine Runden
dreht. Der muss halt dann wieder zurück in die Schule. Schrott konnte
man schon immer programmieren. Wenn es ein Bibliotheks-Programmierer
war, um so schlimmer.

Es gibt aber auch immer mal wieder Dinge, die man nicht mitgeteilt
bekommt, weil die entsprechende Hardware eben keine Interrupts kann.
Dann muss man halt zusehen, die Schleifen so klein wie möglich zu halten
und die Drehzahl so gering wie möglich. USB ist ein Beispiel dafür. Das
läuft die Schleife im USB-Controller ab.


Marcel