[Multithread] Zweiter Thread macht ersten Thread langsam
-
Hallo c-community,
ich habe heute mal eine Frage zu Multithread. Folgende Situation:
Ich habe einen Hauptthread (main) in welchem ich meine Webcam per uvc-Treiber auslese. Dies mache ich indem ich 5 Speicher per MMAP bereitstelle. Zum Auslesen wird ein Speicher mit VIDIOC_DQBUF dequeue´d kopiert und wieder (mit VIDIOC_QBUF) gequeue´d. Funktioniert auch alles wunderbar. Als single-thread-Programm dauert dies < 1sec.
Jetzt möchte ich einen 2. Thread hinzufügen, der mir per XLib das Bild in einem Fenster anzeigt. Dazu soll (später) das Struct für die Camera von Haupt- und Neben-Thread genutzt werden.
Jetzt ist mir aber aufgefallen, dass allein das Starten des 2. Threads (pthread_create) anscheinend Einfluss auf meinen ersten Thread hat (der 2. Thread wird nur initialisiert mit pthread_create und läuft dann erstmal in einer while-Schleife ohne jegliche Aktivitäten). Die Andwortzeiten des 1.Threads zum Auslesen der Kamera verschlechtern sich dadurch aber schon drastisch (Auslesezeit >2sec).Verwendete CPU ist ein 2-Kernprozessor (Intel).
Wieso verschlechtert sich die Zugriffszeit auf meine Webcam schon durch einen 2. Thread so dramatisch? Muss ein sowas wie ein Sleep() in die While-Schleife einbauen, um meine Antwortzeiten des 1. Threads wieder zu verbessern?
MfG
mirrowwinger
-
mirrowwinger schrieb:
Wieso verschlechtert sich die Zugriffszeit auf meine Webcam schon durch einen 2. Thread so dramatisch? Muss ein sowas wie ein Sleep() in die While-Schleife einbauen, um meine Antwortzeiten des 1. Threads wieder zu verbessern?
Das while sagt dem 2. Thread ja "loope so schnell wie Du kannst ohne Pause und Unterbrechung, und verschaff Dir dafür alle notwendigen Zeit-Ressourcen die es im System gibt". Da wird der Hauptthread langsamer.
Wie Du schreibst, entweder ein sleep, damit der 2. Thread das tut was er eigentlich soll (schlafen bis was passiert), oder auf ein Event warten, das ihn aufweckt.
-
Marc++us schrieb:
mirrowwinger schrieb:
Wieso verschlechtert sich die Zugriffszeit auf meine Webcam schon durch einen 2. Thread so dramatisch? Muss ein sowas wie ein Sleep() in die While-Schleife einbauen, um meine Antwortzeiten des 1. Threads wieder zu verbessern?
Das while sagt dem 2. Thread ja "loope so schnell wie Du kannst ohne Pause und Unterbrechung, und verschaff Dir dafür alle notwendigen Zeit-Ressourcen die es im System gibt". Da wird der Hauptthread langsamer.
emm, 2cores, 2threads.
schau dir die cpu auslasung an ohne den zweiten thread zu starten, falls diese ueber 50% ist (z.b. weil ein cam treiber einen core auslastet), wuerde es erklaeren wieso ein zweiter thread von dir einfluss auf die sache hat.
-
rapso schrieb:
[´...] wuerde es erklaeren wieso ein zweiter thread von dir einfluss auf die sache hat.
Das war doch schon geklärt:
mirrowwinger schrieb:
der 2. Thread wird nur initialisiert mit pthread_create und läuft dann erstmal in einer while-Schleife ohne jegliche Aktivitäten).
Offensichtlich ist mirrowwinger nicht bewußt das eine while-Schleife das genaue Gegenteil von "ohne jegliche Aktivität" ist. Das ist ein busy-wait und belegt immer 100% der zur Verfügung stehenden Performance. (Bei einem dual-core immer 100% eines der Kerne)
-
emm, 2cores, 2threads.
Ich glaube nicht dass es so einfach ist. Der Scheduler wird die Arbeit ( Endlosschleife und Hauptthread ) mal auf diesen und mal auf jenen Core verlagern. Es ist nicht automatisch so einfach, dass immer genau der gleiche Core den gleichen Thread bearbeitet. Oder sind die Scheduler inzwischen intelligenter geworden?
-
@Marc++us, rapso, loks und Ir0101, danke erstmal für eure Beiträge. Das mit dem Sleep werde ich gleich mal probieren (war bis jetzt unterwegs und konnte nicht an meinem Programm weiterarbeiten). Werde auch mal die CPU-Auslastung überprüfen. Aber ich glaube Marc++us hat das schon gut getroffen, was ich falsch mache (Unendlich-Schleife ohne Sleep).
Werde heute Abend nochmal ein Update zum Problem geben und würde mich über weitere Anregungen freuen.
MfG
mirrowwinger
-
It0101 schrieb:
emm, 2cores, 2threads.
Ich glaube nicht dass es so einfach ist. Der Scheduler wird die Arbeit ( Endlosschleife und Hauptthread ) mal auf diesen und mal auf jenen Core verlagern. Es ist nicht automatisch so einfach, dass immer genau der gleiche Core den gleichen Thread bearbeitet. Oder sind die Scheduler inzwischen intelligenter geworden?
Eventuell greift da sowas: http://en.wikipedia.org/wiki/Processor_affinity
-
Also verwende jetzt usleep() genutzt und die Antwortzeiten haben sich wieder auf ein normales Niveau geändert.
-
loks schrieb:
rapso schrieb:
schau dir die cpu auslasung an ohne den zweiten thread zu starten, falls diese ueber 50% ist (z.b. weil ein cam treiber einen core auslastet), wuerde es erklaeren wieso ein zweiter thread von dir einfluss auf die sache hat.
Das war doch schon geklärt:
mirrowwinger schrieb:
der 2. Thread wird nur initialisiert mit pthread_create und läuft dann erstmal in einer while-Schleife ohne jegliche Aktivitäten).
yw
It0101 schrieb:
emm, 2cores, 2threads.
Ich glaube nicht dass es so einfach ist. Der Scheduler wird die Arbeit ( Endlosschleife und Hauptthread ) mal auf diesen und mal auf jenen Core verlagern. Es ist nicht automatisch so einfach, dass immer genau der gleiche Core den gleichen Thread bearbeitet. Oder sind die Scheduler inzwischen intelligenter geworden?
wenn die threads die cores switchen, wird nicht viel rechenzeit draufgehen, nicht um das zu erklaeren:
mirrowwinger schrieb:
Als single-thread-Programm dauert dies < 1sec.
...
der 2. Thread .. läuft ... Die Andwortzeiten des 1.Threads zum Auslesen der Kamera verschlechtern sich dadurch aber schon drastisch (Auslesezeit >2sec)@mirrowwinger
hast du zufaellig ein macbook air?
-
nein einen ca 6 Jahre alten HP Presario. xD
-
mirrowwinger schrieb:
nein einen ca 6 Jahre alten HP Presario. xD
dann gibt es eine chance dass da auch ein core2duo drinnen steckt :).
bei den MBAs mit core2duo wird aus thermischen gruenden gedrosselt wenn man zulange zuviel von der hardware abverlangt, vielleicht passiert dasselbe bei deinem Presario.
aber naja, wenn es nun funzt, funzt es, weshalb auch immer
