Die beste Vorgehensweise ist, nicht abzufragen, aber findet die Abfrage trotzdem intern statt, wenn ein Thread wait () aufruft.

Angenommen, wir haben einen Thread, der prüfen möchte, wann ein anderer Thread seine Aufgabe beendet hat. Ich habe gelesen, dass wir eine Funktion vom Typ wait () aufrufen sollten, die diesen Thread warten lässt, bis er eine Benachrichtigung erhält, dass der andere Thread beendet ist. Und das ist gut so, denn wir führen keine teuren Abstimmungen durch.

Aber findet die interne Abstimmung trotzdem auf einer niedrigeren Ebene statt? Dh, wenn wir den Thread warten lassen (), führt der Kerner dann trotzdem eine Abfrage durch, um zu prüfen, wann der andere Thread fertig ist, damit er den ersten Thread benachrichtigen kann?

Ich nehme an, ich habe hier etwas verpasst, kann mich jemand aufklären?

parallelism multithreading locks

— CSSS
quelle

Das Betriebssystem stellt bestimmte Grundelemente für diese Art der Interprozesskommunikation bereit, für die keine Abfrage erforderlich ist.

Wenn Prozess A auf Mutex M wartet, weiß das Betriebssystem, dass A nicht ausgeführt werden kann, und legt es in einen Eimer mit Prozessen, die darauf warten, dass etwas passiert. Wenn der Prozess, der M enthält, ihn freigibt, überprüft das Betriebssystem die Liste der darauf wartenden Prozesse. Der erste Prozess auf der Liste, möglicherweise A, wird aus dem inaktiven Bucket entfernt und in die Ausführungswarteschlange gestellt . Wenn A das nächste Mal eine Zeitscheibe erhält, kehrt das aufgerufene wait () zurück und das Programm wird fortgesetzt.

— Blrfl
quelle

also in gewisser weise wird doch auf betriebssystemebene abgefragt?

— tgkprog

Nein @tgkprog, dies wird nicht abgefragt, da die Ausführung des Wartevorgangs erst geplant ist, wenn das Betriebssystem oder ein anderer Prozess den Mutex freigibt. Ein Abfrageprozess würde weiterhin in der CPU-Planung konkurrieren, um zu prüfen, ob er aufhören sollte zu warten. Ein solcher Abfrageprozess kann einen erheblichen Teil der CPU-Zeit in Anspruch nehmen, während er wartet.

— Joshp

Ich meinte, der OS-Prozess fragt den Mutex-Status ab. obwohl ich sicher bin, dass es optimiert und besser ist als alles, was wir tun könnten. Läuft wahrscheinlich als Teil des Schedulers.

— tgkprog

@tgkprog: Das Betriebssystem achtet nicht ein bisschen darauf, was mit einem Mutex passiert, bis der Prozess, der es hält, es freigibt oder beendet. Jedes dieser Ereignisse führt dazu, dass das Betriebssystem die Mutex-Sperre an den Prozess weitergibt, der sich zuerst auf der Warteliste befindet, und diesen Prozess als ausführbar markiert. Es gibt keine Umfragen, nur eine Reaktion auf ein Ereignis. Alles, was joshp sagte, ist als Referenz enthalten. :-)

— Blrfl

@ CSSS: Ziemlich viel. Prozesse können freiwillig (z. B. Aufrufen _exit(2)von POSIX-y-Systemen) oder unfreiwillig (z. B. ein Fehler wie eine Division durch Null erzeugt einen Interrupt oder andere Aufrufe kill(2)) beendet werden. In beiden Fällen wird die Steuerung explizit an das Betriebssystem zurückgegeben, das weiß, welcher Prozess ausgeführt wurde oder beendet werden soll. Das Beenden eines Prozesses umfasst das Freigeben seiner Ressourcen, einschließlich Mutexe. Wenn ein Mutex vom jetzt toten Prozess gehalten wurde, gibt das Betriebssystem ihn frei. Wenn der Prozess auf der Warteliste des Mutex war, wird er entfernt.

— Blrfl