Wieso 100% CPU-Last

  • Hallo Code-Gurus,


    das folgende Progrämmchen ist nicht von mir selbst. Es ist Bestandteil von diesem Archiv.


    Erst mal zur Erklärung, was das Programm überhaupt macht:


    Das Programm dient dazu, die DTR-Leitung einer seriellen Schnittstelle auf HIGH oder LOW zu setzen. Mittels dieser Leitung wird eine an die serielle Schnittstelle angeschlossene Relaiskarte gesteuert, an der Wiederum mein TFT angeschlossen ist.


    Um es in Betrieb zu nehmen, muss zunächst die gewünschte serielle Schnittstelle verlinkt werden auf /dev/powerswitch, in meinem Fall ist dies /dev/ttyS1 (also COM2). Dann wird mittels "mkfifo -m 0666 /dev/powerctrl" ein FIFO angelegt, an den die Signale (0,1,T) gesendet werden können.


    So weit so gut, wenn das Programm gestartet ist (powerswitch &), lässt sich mit "echo SIGNAL > /dev/powerctrl" die Relaiskarte schalten.


    Leider verbraucht das Programm aber, nachdem es das erste Signal gelesen hat, 100% CPU.


    Hier mal der Original-Code:



    Ich vermute mal, das Problem liegt irgendwo am Anfang der while(1)-Schleife (ist das Busy-Waiting?). Aber irgendwie steh ich grad auf dem Schlauch. Vielleicht sieht ja jemand eine einfache Lösung für das Problem mit 100% CPU.


    Vielen Dank schonmal,
    fitzefatze

  • Auf den ersten Blick würde ich sagen, du hast einen Denkfehler in der Pipe.


    Nachdem das Echo-Kommando das Signal in die Pipe geschickt hat, wird die Pipe geschlossen, und damit geht auch das andere Ende der Pipe in deinem Programm in den Zustand EOF. Du musst dann die Pipe schließen und erneut öffnen, wenn du weiter Daten lesen willst.


    Gruß,


    Udo

  • Aber wenn die Pipe zu wäre, würde das doch heißen, dass auch keine weiteren Zeichen gelesen werden können, ohne die Pipe neu zu öffnen, oder seh ich das falsch? ?(


    Das Programm nimmt aber weiterhin Zeichen aus der Pipe entgegen, mehrfaches hin- und herschalten des Relais ist kein Problem, nur dass eben die CPU-Last auf 100% steigt.


    Hab inzwischen etwas rumgelesen und dabei interessante Sachen zu select() gefunden. Wie ich das sehe, überwacht select() einen oder mehrere Sockets/Dateideskriptoren und zeigt an, ob diese lesebereit sind. select() sollte eigentlich blockieren... was mich noch mehr rätseln lässt, wo die 100% herkommen.



    Wäre es nicht einfacher, einen einfachen blockierenden Leseaufruf zu verwenden? Das Programm liest ja nur aus einer Pipe und nicht aus mehreren gleichzeitig. Oder ist das kompletter Bullsh*t, was ich mir hier überlege? Hab leider nicht so die riesen Erfahrung im C-Programmieren. :rolleyes:

  • Zitat

    Original von Urig
    Nachdem das Echo-Kommando das Signal in die Pipe geschickt hat, wird die Pipe geschlossen, und damit geht auch das andere Ende der Pipe in deinem Programm in den Zustand EOF. Du musst dann die Pipe schließen und erneut öffnen, wenn du weiter Daten lesen willst.


    ... genau das.


    Kommt davon, wenn man die Programme selbst nur kurz testet.


    Viele Grüße, Mirko

  • Aus der man-page für select:


    Zitat

    Three independent sets of descriptors are watched. Those listed in readfds will be watched to see if characters become available for reading (more precisely, to see if a read will not block - in particular, a file descriptor is also ready on end-of-file)


    Aus der man-page für read:

    Zitat

    On success, the number of bytes read is returned (zero indicates end of file)


    Dein Programm ist also immer sofort aus dem select erwacht, und hat beim nachfolgenden read 0 Bytes gelesen.


    Nebenbei, hier dürfte dir die Klammer verrutscht sein: read(terminal, &buffer, sizeof(char) == 1)


    Gruß,


    Udo

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!