Warum kann ein Mutex nicht in der unteren Hälfte erworben werden?

Question

Ich lese < < Linux Kernel Entwicklung >> und durch die Unterschiede zwischen Mutex verwirren lassen und Semaphore

der Autor sagt, „Ein Mutex kann nicht durch einen Interrupt-Handler oder untere Hälfte erworben werden“, ich weiß, ein Mutex führen kann zu schlafen, und Interrupt-Handler wird nicht in einem bestimmten Prozesskontext ausgeführt, so dass Mutex oder Semaphor nicht zulässig ist. Die untere Hälfte kann jedoch mit Arbeitswarteschlangen implementiert werden und sie kann schlafen.

Also, warum ein Mutex kann nicht in der unteren Hälfte erworben werden? Geht es hier um Einfachheit und Effizienz oder um etwas anderes?

Answer 1

Das Hauptmotiv für die Erstellung eines Mutex ist Einfachheit und Effizienz. Da die Synchronisierung in den unteren Hälften kompliziert sein kann, wird vorgeschlagen, Mutex in den unteren Hälften zu vermeiden. Das Design der unteren Hälften ist nicht für Mutex geeignet. Z.B. Mutex sollte im selben Kontext gesperrt/entsperrt werden - dies wäre im Falle von unteren Hälften schwer zu folgen.

In der Theorie können Sie entscheiden, die gesamte Interrupt-Handhabung zu implementieren, in der Verwendung von Mutex in gerechtfertigt ist. Wie die "Threaded" Interrupt-Handler. http://lwn.net/Articles/380931/

Answer 2

Mutex/Semaphor Verriegelung kann schlafen, aber BHs sind entworfen, nicht zu schlafen. Softirqs werden an vielen Stellen asynchron auf ihre Ausführung überprüft. Zum Beispiel können sie jedes Mal ausgeführt werden, wenn Sie BH wiederherstellen (wie spin_unlock_bh). Es ist eine sehr schlechte Idee, solchen Code zu verursachen, um auf einem Mutex zu schlafen. Wenn Sie schlafen, während Sie einen BH-Spinlock halten, können Sie anderen BH-Code zum Schlafen bringen und vielleicht sogar das gesamte System blockieren.

Von diesem Standpunkt aus sind die Workqueues nicht betrachtet BH, sie laufen im Zusammenhang mit Kernel-Threads, die frei sind zu schlafen. Ein Mutex ist also für Workqueues in Ordnung, aber nicht für Tasklets.

BH ist ein vager Begriff, ich finde es hilfreich zu denken, der Linux-Kernel habe drei Ausführungskontexte: Benutzer (einschließlich Kernel-Threads), Softirq und Hardirq. Preempting von jedem von diesen kann mit einer Reihe von Bits in preempt_count gesteuert werden.