Ersatz für DOS-Int 15h Funkt. 83h (Timer)

[RSE]

Du meinst also man sollte blockierende Read-Befehle auf dem Port verwenden? Die warten ja dann, bis auf dem Port was ankommt und dann geht´s erst weiter. Was passiert dann eigentlich, wenn das Programm vorher beendet werden soll? Muss dann der Thread "abgeschossen" werden? Hab selbst kaum Ahnung von Threads.

[theo]

Du meinst also man sollte blockierende Read-Befehle auf dem Port verwenden? Die warten ja dann, bis auf dem Port was ankommt und dann geht´s erst weiter. Was passiert dann eigentlich, wenn das Programm vorher beendet werden soll? Muss dann der Thread "abgeschossen" werden? Hab selbst kaum Ahnung von Threads.

Da kann man nat. Dinge tun, die man sonst nicht tun kann.
Bspw. kann man einen wartenden TTCPBlockSocket in einem Child-Thread einfach vom Haupt-Thread aus abwürgen afaik.
Wenn das Terminated flag gesetzt ist, wird dann der Thread beendet.

[mschnell]

Wenn das Terminated flag gesetzt ist, wird dann der Thread beendet.

Leider nein. Der Mainthread kann TThread.Terminate aufrufen oder TThread.Terminated := True setzem , um dem Thread zu sagen, dass er sich beenden soll, indem er auf die Execute - Prozedur verlässt. Leider kann er dass in einem blocking Read nicht tun . Ich schaue morgen 'mal nach wie man ein Blocking read mit Timeout macht.

-Michael

[AlterMann]

Es ist ja dann auch ein Interrupt-Service. Allerdings im Treiber. Im Userland-Code ist das bei Linux und Windows nicht möglich.

Und genau da hakt's bei mir im Augenblick.
Auch wenn ich euch bestimmt schon auf die Nerven gehe, aber das will einfach nicht in meinen Schädel.
Ihr sagt mir - zurecht - ich soll weg von meinen alten Denkmustern, hin zu ereignisgesteuerter Programmierung.
Auch wenn (treiberintern) eine ISR läuft und die empfangenen Zeichen in einen Buffer schreibt, sobald ich (auf Verdacht) jenen Buffer abragen muß ob was drin ist, ist das wieder Pollingbetrieb.
Warum löst der Treiber dann kein Event aus, beim Empfang eines Zeichens?

Der Vorschlag von Theo in der TThreadprocedure den Buffer zu Pollen und mit einem Sleeptimer zu verhindern, daß die TThreadprocedure die ganze Rechenzeit frisst, ist zwar wahrscheinlich das beste was man aus der vorhandenen Situation machen kann, aber befriedigend ist es irgendwie nicht.

Entweder habe ich noch nicht durchschaut wo es hängt oder aber (in diesem speziellen Punkt) hat es einen Rückschritt gegeben.
Ich glaube nämlich sehr wohl, daß der IRQ-Baustein intern verwendet wird, nur habe ich auf Anwendungsebene nix davon ...

[af0815]

Entweder habe ich noch nicht durchschaut wo es hängt oder aber (in diesem speziellen Punkt) hat es einen Rückschritt gegeben.
Ich glaube nämlich sehr wohl, daß der IRQ-Baustein intern verwendet wird, nur habe ich auf Anwendungsebene nix davon ...

Zwischen Dir und dem I/O Port liegen einige Schichten, die den Zugriff auf die Hardware abstrahieren.

Kurzum bei den 'neuen' Systemen greifst du nicht direkt auf die Hardware durch, sondern auf eine virtuelle. Diese greift dann über den Treiben auf die wirkliche durch.
Bsp. Serielle über USB. Dort greifst du auf den Port zu, das löst einen entsprechenden Softwareinterupt aus, der über den USB Treiber auf den Schnittstellenbaustein das entsprechende Hardwareregister ausliest. Somit greifst du in wirklichkeit auf etwas zu, was es gar nicht gibt und unter DOS etc. gar nicht funktionieren würde.

[mschnell]

./.

[mschnell]

./.

[mschnell]

./.

[mschnell]

ist das wieder Pollingbetrieb.

Nein, Der Timeout ist ja einige Sekunden, also viel langsamer als der Zeichenempfang. Gepollt wird nur auf Thread-Abbruch.

Warum löst der Treiber dann kein Event aus, beim Empfang eines Zeichens?

Events sind eine Angelegenheit der speziellen Programmiersprache viele Sprachen bieten so etwas garnicht. Zwischen Treiber und Programmiersprache und Treiber liegt nach das OS, das alle Programmiersprachgen unterstützen muss. Zwischen OS und Anwenderprogramm gilt der Posix-Standard. Da gibt es, soweit ich weiß, keine Events.

Der Vorschlag von Theo in der TThreadprocedure den Buffer zu Pollen und mit einem Sleeptimer zu verhindern, daß die TThreadprocedure die ganze Rechenzeit frisst, ist zwar wahrscheinlich das beste was man aus der vorhandenen Situation machen kann, aber befriedigend ist es irgendwie nicht.

Genau. Frisst zwar nicht 100% Rechenzeit, aber bei langem, Sleep wird die Datenrate geringer und bei kurzem Sleep die CPU-Last höher. Keine Anpassung an die tatsächliche Datenrate,

Entweder habe ich noch nicht durchschaut wo es hängt oder aber (in diesem speziellen Punkt) hat es einen Rückschritt gegeben.

Wie man's nimmt. Standardisierung ist immer ein Rückschritt in Bezug auf Performance und Einfachheit eines bestimmten Problems, aber ein Fortschritt im "globalen"

Ich glaube nämlich sehr wohl, daß der IRQ-Baustein intern verwendet wird, nur habe ich auf Anwendungsebene nix davon ...

Genau. Wenn jedes Programm sich einzeln um Hardware-Interrupts kümmern müsste, könnten nicht viele zusammen auf einem Rechner laufen (von Portierbarkeit wollen wir gar nicht erst reden <siehe af0815>). So was ist nur im Embedded-Bereich sinnvoll. und auch da zieht Linux immer größere Kreise.

-Michael

[RSE]

ist das wieder Pollingbetrieb.

Nein, Der Timeout ist ja einige Sekunden, also viel langsamer als der Zeichenempfang. Gepollt wird nur auf Thread-Abbruch.

Polling heißt für mich immermal prüfen, ob eine Bedingung erfüllt ist. Demnach ist das vergeschlagene Vorgehen (Timer stellen und immer nach x Zeit nachsehen, ob Daten vorliegen) für mich Polling. Etwas Event-ähnliches wäre ein blockierender Aufruf, bei dem aber wieder das Problem eines Abbruchs ohne Datenempfang besteht. Regelt man den Abbruch mittels Timeout, dann könnte man das als Polling auf Thread-Abbruch bezeichnen, aber darauf hat sich AlterMann in dem Satz nicht bezogen, wenn ich das richtig interpretiere

Zwischen OS und Anwenderprogramm gilt der Posix-Standard. Da gibt es, soweit ich weiß, keine Events.

Was sind dann Windows-Messages, die du z.B. bekommst, wenn eine bestimmte Datei geändert wurde, DirectShow mit der Wiedergabe eines Songs fertig ist, ein Fenster geschlossen werden soll etc.? Für mich sind das alles Events des Betriebssystems.

..., aber bei langem, Sleep wird die Datenrate geringer und bei kurzem Sleep die CPU-Last höher.

Es ist ja wohl kein Problem den Timer zu benutzen, um herauszufinden, ob überhaupt Daten ankommen und dann den gesamten Puffer auf einmal zu leeren. Falls dann noch weitere Daten zu erwarten sind, kann ein entsprechend an die Puffergröße angepasster Timerwert verwendet werden. Sobald man davon ausgeht, dass hier der Flaschenhals an der Datenübertragungsrate der Hardware liegt und nicht am verarbeitenden Programm, kann man so nicht mehr von verringerter Datenrate reden. Aber das betrifft die ursprüngliche Fragestellung auch nur noch sehr peripher!

Standardisierung ist immer ein Rückschritt in Bezug auf Performance und Einfachheit eines bestimmten Problems

Das kann so allgemein wohl nicht stehen bleiben. Bestenfalls kann man sagen, dass es immer ein Problem geben wird, welches sich durch eine Standardisierung verkompliziert. Der Großteil sollte dabei vereinfacht werden, denn das ist der Zweck der Standardisierung. Wie kompliziert ein Problem ist, beinhaltet für mich nämlich auch, wie verständlich die Umsetzung der Lösung ist, und genau da liegt der Vorteil von Standards. Man kennt sie und sie treten überall wieder auf. Der unbekannte Anteil sinkt.

[mschnell]

Es ist ja wohl kein Problem den Timer zu benutzen, um herauszufinden, ob überhaupt Daten ankommen und dann den gesamten Puffer auf einmal zu leeren.

Das verhindert immer noch eine schnelle Reaktion auf die ankommenden Daten. Z.B. eine Antwort auf einen Datenblock in einem Kommunikations-Protokoll.

--Michael

[RSE]

Richtig, aber das ist was anderes als die Datenrate. Die Frage ist nun, wie reaktionsschnell muss das ganze sein? Ich glaue nicht, dass die CPU-Last bei 10ms Polling-Intervall auffällt, und das sollte für die meisten Fälle mehr als schnell genug sein. Aber das sollte AlterMann wohl besser wissen.

[AlterMann]

Was sind dann Windows-Messages, die du z.B. bekommst, wenn eine bestimmte Datei geändert wurde, DirectShow mit der Wiedergabe eines Songs fertig ist, ein Fenster geschlossen werden soll etc.? Für mich sind das alles Events des Betriebssystems.

Genau das hätte ich auch gedacht, die Mausklicks, Tasaturevents ...
Irgendwie hab ich das Gefühl um die serielle SS pfeift sich keiner mehr, weil die eh ausstirbt (glaubt man) ...

Im konkreten Fall kommt unter Umständen stunden- bis tagelang nichts vom externen Gerät.
Aber wenn dann was kommt schickt das Gerät ein best. Zeichen, wartet auf ein anderes als Antwort, schickt daraufhin einen String (6-30 Zeichen lang) wartet auf ein Ack.
Natürlich wird sich dieses spezielle Problem mit einem Timer lösen lassen ...... und die nächste Aufgabenstellung wieder, aber ein bißchen anders ...
Aber sei's wie sei, ich muß mich da erst einmal ein bißchen reinknien und schauen wie ich das am besten löse

Danke für die zahlreichen Antworten.
Christian

[mse]

Irgendwie hab ich das Gefühl um die serielle SS pfeift sich keiner mehr, weil die eh ausstirbt (glaubt man) ...

Für Diese Anwendung gibt es doch sicher Komponenten? Ich kenne leider nur meine eigenen aus MSEgui und kann dir für Lazarus keine entsprechende nennen. Mit der Windows API geht das mit WriteFile() mit lpOverlapped Parameter:
http://msdn.microsoft.com/en-us/library ... S.85).aspx
ReadFile() mit lpOverlapped Parameter:
http://msdn.microsoft.com/en-us/library ... S.85).aspx
WaitforSingleObject():
http://msdn.microsoft.com/en-us/library ... S.85).aspx
und GetOverLappedResult():
http://msdn.microsoft.com/en-us/library ... S.85).aspx
welche in einen separaten thread laufen.
Beispielcode gibt es in der ziemlich betagten unit msecommport:
http://mseide-msegui.svn.sourceforge.ne ... s?view=log
oder auch in tpipereader:
http://mseide-msegui.svn.sourceforge.ne ... n&view=log

Martin

[mschnell]

Beispielcode gibt es in der ziemlich betagten unit msecommport:
http://mseide-msegui.svn.sourceforge.ne ... s?view=log
oder auch in tpipereader:
http://mseide-msegui.svn.sourceforge.ne ... n&view=log

WOW !
Tuts das auch mit NoGUIApplication ?

-Michael