Timed Semaphore in linux
-
Ich habe es schon einmal gesagt und ich sage es noch einmal:
SeppJ schrieb:
top ist kein Tool zum Programmprofiling.
Nimm einen Profiler, wenn du wissen möchtest, wie viel CPU-Last dein Programm wirklich erzeugt.
-
Das ist mir schon klar, aber wenn ich 10 Threads starte und dort zehnmal immer 1ms warten lasse, dann habe ich eben 10 x 2% = 20% CPU-Last.
Irgendwann entkräftet sich auch dein Argument mit dem Profiler. 20% Last, selbst wenn sie "nur" von "top" gemeldet werden, kann man wohl nicht mehr wegdiskutieren und wenn in Wirklichkeit tatsächlich keine Last vorliegt, aber "top" 20% anzeigt, dann muss irgendwann einfach mal zu der Erkenntnis kommen, dass Linux doch nicht so der Oberbrüller ist.
-
It0101 schrieb:
Es muss dafür ne bessere Lösung geben. Ich bin schließlich nicht der einzige der unter Linux mehrere Threads betreiben will, bzw. es tut.
Vielleicht kann ich auch meine Konstruktion so umbauen, dass die wartende Semaphore nicht notwendig ist.
Es handelt sich bei meinen Threads im wesentlichen um Sockethandler. D.h. die beschäftigen sich mit select, accept, recv und send.
Insbesondere bei den Threads, die Sockets lesen sind natürlich längere Wartezeiten nicht akzeptabel, da sie die Latenz in die Höhe schrauben. Es ist in dem Fall so, dass dieser besagte Thread nicht nur auf ein recv wartet sondern auch auf serverinterne Messages aus einer Queue.
Die Semaphore soll auch nur dann warten, wenn der Thread nichts zu tun hatte ( nichts received und auch nichts aus der internen Queue verarbeitet ).
Dein Konzept ist falsch. Es macht keinen Sinn auch nur kurz zu warten. Entweder der Thread hat was zu tun oder er wartet, dass er was zu tun bekommt. Und wenn er wartet, dann sollte es kein Busy-Wait sein und auch kein ein wenig Busy-Wait indem Du nur mal immer kurz wartest, so wie Du es versuchst.
Dein Thread soll also auf Daten vom Socket und gleichzeitig auf eine Semaphore warten. Das geht so nicht. Du kannst unter Linux/Unix auf mehrere Sachen Warten, wenn es Filedeskriptoren sind. Dann kannst Du mit select oder poll (oder unter Linux epoll) auf Ereignisse warten. Der Thread kann dann mit einem unendlichen Timeout warten. Er wird dann erst geweckt, wenn wirklich was zu tun ist.
Das löst man normalerweise so, dass man in den select oder poll neben dem Socket-Deskriptor noch eine Pipe dazu packt. Wenn ein anderer Thread dann dem Thread eine Nachricht schicken will, schreibt er in die Pipe und unterbricht das Warten. Der wartende Thread kann dann darauf reagieren.
Wenn Du dann 10 oder 100 oder 1000 Threads hast, die alle auf select oder poll warten, dann erzeugt das keine Last.
-
It0101 schrieb:
Das ist mir schon klar, aber wenn ich 10 Threads starte und dort zehnmal immer 1ms warten lasse, dann habe ich eben 10 x 2% = 20% CPU-Last.
Nein. Milchmädchenrechnung.
Irgendwann entkräftet sich auch dein Argument mit dem Profiler. 20% Last, selbst wenn sie "nur" von "top" gemeldet werden, kann man wohl nicht mehr wegdiskutieren
Doch. Milchmädchenrechnung. Wenn dir wirklich klar wäre, was top anzeigt, dann würdest du das auch verstehen.
und wenn in Wirklichkeit tatsächlich keine Last vorliegt, aber "top" 20% anzeigt, dann muss irgendwann einfach mal zu der Erkenntnis kommen, dass Linux doch nicht so der Oberbrüller ist.
Nein, dann kommt man zu der Erkenntnis, dass top kein Profilingwerkzeug ist
.
-
It0101 schrieb:
dann muss irgendwann einfach mal zu der Erkenntnis kommen, dass Linux doch nicht so der Oberbrüller ist.
Ja, du hast Recht. Linux ist total langsam. Wenn es um Rechenpower und Stromsparen geht, ist Windows viel viel besser.
*ich gebs auf*
-
SeppJ schrieb:
Nein, dann kommt man zu der Erkenntnis, dass top kein Profilingwerkzeug ist
.Dann kommt wenn schon denn schon zur Erkenntnis, das zumindest die CPU-Werte im Top eigentlich garnix aussagen.
-
tntnet schrieb:
Wenn Du dann 10 oder 100 oder 1000 Threads hast, die alle auf select oder poll warten, dann erzeugt das keine Last.
Genau das ist im Prinzip auch die Lösung die ich anstrebe. Die ist rein logisch und technisch auch sauberer als das Mini-Wait, was ich derzeit verwende.
