Making-Threads erhalten gleiche Timeslices

8

Ich führe dieses Programm aus, wo ich mehrere Threads habe. Drei Threads erzeugen Signale für den gleichen übergeordneten Prozess. Es gibt vier Handler-Threads zum Handhaben der Signale, die von den signalerzeugenden Threads erzeugt werden. Ich habe einen Überwachungs-Thread, der auch die Signale und Prozesse entsprechend empfängt. Ich habe jedoch eine Situation. Ich kann sehen, dass die Signale nicht gleichmäßig verteilt sind. Ich meine, die Signale sind auf den gleichen Prozess gerichtet. Ich habe vier Handler-Threads und einen Überwachungs-Thread, der auf das Signal wartet. So kann jeder von ihnen das Signal empfangen. Ich habe erwartet, dass es gleichmäßig verteilt wird. Allerdings konnte ich sehen, dass zu der Zeit eine ganze Reihe von Signalen von den Handler-Threads empfangen wird. Das nächste Mal wird der gesamte Signalburst vom Monitor-Thread verarbeitet. Warum ist es nicht einheitlich? Ich habe einen Schlafanruf hinzugefügt, nachdem die Handler / Monitor-Threads die Behandlung eines Signals abgeschlossen haben. Sobald der Handler / Monitor ein Signal abgeschlossen hat, sollte er die andere Möglichkeit erhalten haben, das nächste Signal zu verarbeiten. Die Ausgabe zeigt jedoch nicht den Fall

%Vor%

Hier ist meine Ausgabe

%Vor%

Sie können den Burst des Monitors sehen, gefolgt von einem Burst des Handlers. Sobald jedoch ein Handler / Monitor ein Signal verarbeitet und auf sigwait zugreift, habe ich im Code einen Schlafanruf hinzugefügt, so dass die Runde an den nächsten verfügbaren Thread übergeben wird. Dies hilft jedoch nicht. Das hätte es wahrscheinlich einheitlich gemacht. Der Monitor wird jedoch geplatzt und gedruckt. Auch wenn ich auf dem Monitor den Ruhezustand eingestellt habe, nachdem es seine Arbeit für ein Signal beendet hat

    
user34790 27.09.2012, 14:41
quelle

2 Antworten

3

Welches Betriebssystem verwenden Sie? Sie brauchen ein Echtzeit-Betriebssystem (RTOS), um das zuverlässig zu machen. Ich hatte gute Ergebnisse mit einem sehr kleinen RTOS namens On Time RTOS-32 , um eine Robotersteuerung zu steuern. Es kann Time-Slicing mit garantierter Latenzzeit durchführen, oder Sie können eine kooperative Planung durchführen. Es hat eine Windows-Emulation für eine Teilmenge der Win-API festgelegt. Wir haben Visual Studio / VC ++ als IDE verwendet. Es kann jetzt eine ziemlich gute Auswahl an RTOS geben. Das war vor fast 10 Jahren. Google für RTOS und "Echtzeit-Betriebssystem."

Die Alternative, die auf einer schnellen dedizierten Maschine gut genug sein kann, besteht darin, ein eigenes "Betriebssystem in einem Betriebssystem" zu schreiben, um die Threads "von Hand" zu planen. Sie müssten die Art ändern, wie die Threads auf Zuweisungen warten.

Ich fotografiere im Dunkeln. Warum müssen Sie die Last zwischen den Threads ausgleichen? Was ist die Aufgabe? Was ist das Budget? Muss es auf bestimmter Hardware laufen? Auf einem bestimmten Betriebssystem? Wenn ja welches? Was passiert, wenn es plonk geht? Jemand murmelt ein schlechtes Wort und geht zum Mittagessen, oder eine Raumsondennase taucht in die Sonne?

    
Jive Dadson 05.10.2012 19:05
quelle
1

OS haben keine Ahnung, dass Sie einen JOB zwischen mehreren Threads verteilen möchten, also führt OS den ersten verfügbaren Thread mit der höchsten Priorität aus, der Thread wird weiter ausgeführt, bis der aktuelle Thread auf etwas wartet (Benutzereingabe, Festplatten- oder Netzwerkaktivität oder .. .) oder ein anderer Thread mit höherer Priorität verfügbar. - Um die Leistung zu steigern und zu viele Kontextwechsel zu vermeiden, versuchen OS, die Anfrage für denselben Thread (im Gegensatz zu Ihrem Bedarf) zu versenden.

Betrachten wir zum Beispiel MonitorThread für die Ausführung geplant und sein Aufruf an sigwait ist erfüllt, jetzt macht es seine Aktion (während dieser Thread eigene CPU, OS hat keine Möglichkeit andere Threads zu planen), wenn seine Aktion abgeschlossen ist (Ende von while) es ruft sigwait auf, wenn dort irgendein Signal ansteht, wird das OS dieses Signal aufnehmen und die Schleife erneut durchlaufen, dieser Thread wird diesen Prozess durchführen, bis kein Signal mehr ansteht und sigwait seine Operation blockiert und das nächste Mal die Die Operation wird mit einem anderen geplanten Thread wiederholt.

Um nun Signale gleichmäßig zu verteilen, muss ich meinen eigenen Mechanismus implementieren (da OS dafür keinen Mechanismus haben). Ich kann ein condition_variable für jeden Thread erstellen und erzwinge, dass jeder zuerst auf sein eigenes condition_variable wartet und dann sigwait aufruft und nach Abschluss der Ausführung condition_variable des nächsten Threads setzt und die Operation so geht!.

    
BigBoss 03.10.2012 07:34
quelle