2017-10-27 2 views
3

Kann mir jemand erklären, wie Nachrichtenwarteschlangen mehrere Threads verarbeiten, die in einer einzelnen Nachrichtenwarteschlange blockiert sind?POSIX-Nachrichtenwarteschlange - mq_send Thread-Aktivierungsreihenfolge

Meine Situation ist, ich habe mehrere Autoren blockiert auf eine vollständige Nachricht Warteschlange, jeder Beitrag Nachrichten mit Priorität gleich dem Thread Priorität. Ich möchte sicherstellen, dass sie in der Prioritätsreihenfolge wecken und posten, aber meine Anwendung verhält sich so, als ob sie in der FIFO-Reihenfolge aufwachen würden (d. H. In der Reihenfolge, in der sie blockiert wurden). Jeder blockierende Thread ist geplant mit der SCHED_FIFO-Richtlinie mit einer anderen Priorität mit System-Level-Bereich.

ich gesucht habe das Internet hoch und niedrig für etwas beschreiben, wie dies funktionieren soll und alles, was ich Seiten Mann POSIX finden beschreiben, dass mehr Blocker wecken in Prioritätsreihenfolge wenn Priority Scheduling wird unterstützt. Da der Kernel-Scheduler ein Prioritäts-Scheduler I ist, würde ich meinen, dass die Threads in der Prioritätsreihenfolge aufwachen und die Warteschlange an senden würden, dies scheint jedoch nicht der Fall zu sein. Ich bin sicher, ich bin nur etwas subtile Detail fehlt und ich hoffe, dass die Experten hier auf diese Liste kann helfen, etwas Licht auf was ich sehe, seit seiner bei der Kernel-Ebene, dass diese Threads bereit gemacht werden zu laufen .

Ich habe eine kleine Testanwendung, die ich hier bei Bedarf veröffentlichen kann. Es füllt einfach eine Warteschlange aus und hat dann ein paar Threads, die alle versuchen und schreiben, alle mit unterschiedlichen Threadprioritäten und mit einer Nachrichtenpriorität gleich der Threadpriorität. Ich entferne dann eine Nachricht aus der Warteschlange und erwarte, dass der Thread mit der höchsten Priorität aufwacht und seine Nachricht veröffentlicht. Der erste wartende Thread sendet jedoch zuerst seine Nachricht.

Irgendwelche Hilfe oder Dokumentation kann mir jemand zeigen, um auf den Grund davon zu kommen?

Vielen Dank im Voraus!

+0

Haben Sie überprüft, dass die Priorität der erstellten Threads die von Ihnen gewünschte ist? Normalerweise legt 'pthread_create (3)' die Priorität eines neuen Threads fest, um die Priorität des erzeugenden Threads zu erben. Selbst wenn Sie beim Erstellen eines Threads eine neue Priorität als Planungsparameter übergeben, wird dieser Wert ignoriert, sofern Sie nicht explizit angeben sonst. – bnaecker

+0

Ja, ich habe überprüft, dass die Prioritäten korrekt sind. Ich setze sie explizit, entweder im pthread_attr_t, der an pthread_create() übergeben wurde, oder indem ich pthread_setschedparam() aufruft, wenn ich std :: thread verwende. – jhaws

Antwort

1

Es stellt sich heraus, dass der Linux-Kernel den Prioritätswert der Tasks betrachtet, wenn die Warteschlange voll ist, und sie zu einer Warteschlange in der Tasznichtigkeitsreihenfolge hinzufügt (dies ist die Prioritätsreihenfolge für Nicht-RT-Tasks). Die Warteschlange berücksichtigt keine Echtzeitprioritäten, die meine Anwendung verwendet. Nicht-RT-Prioritäten (nette Werte) werden korrekt behandelt und wachen in der Reihenfolge der Nichtigkeit auf.

Die Ursache für mein Problem in, wie der Kernel Prioritäten beim Hinzufügen von Aufgaben zu den internen Kernelwartewarteschlangen behandelt. Ich habe einen Patch an die Linux-Kernel-Liste gesendet, der akzeptiert wurde und in zukünftige Releases gerollt wird, was die Prioritätsprüfung beim Hinzufügen von Aufgaben zur Warteschlange ändert - er berücksichtigt jetzt sowohl Nicht-RT-Priorität als auch RT-Priorität. Es behandelt KEINE Prioritäten der termingesteuerten Aufgaben.