2016-06-01 10 views
2

Ich arbeite mit Linux Mutex zum Schützen von Daten in Multi-Thread-Anwendung zu teilen. Zum Verhindern der Prioritätsinversion verwende ich das Protokoll PTHREAD_PRIO_INHERIT (http://linux.die.net/man/3/pthread_mutexattr_setprotocol).
Mein System haben drei Threads:
Thread 1: niedrige Priorität, erwerben Mutex zuerst
Thread 2: die gleiche Priorität mit Thread 1. Kein Zugriff teilen Daten.
Thread 3: hohe Priorität. Mutex nach Thread 1 erwerbenLinux Mutex Priorität erben

Angenommen, Thread 1 wird erstellt und zuerst ausgeführt, dann werden die Freigabedaten gesperrt.
Thread 3 dann erstellen und ausführen, nach einer Millisekunde, erhalten Sperre, die Thread 1 besitzt. Also Thread 3 ist blockiert.
Beim PTHREAD_PRIO_INHERIT-Protokoll wird Priorität von Thread 1 auf Priorität von Thread 3 angehoben.
Nach Thread 1 die Sperre aufheben, dann wird Thread 3 ausgeführt und beendet.
Also, meine Frage ist: welcher Thread wird als nächstes ausgeführt, Thread 1 oder Thread 2?

Wer hilft?

Antwort

0

Nach dem POSIX standard:

Wenn Gewinde auf dem Objekt durch Mutex verwiesen Mutex blockiert sind wenn pthread_mutex_unlock() genannt wird, in der Mutex resultierende verfügbar werden, wird die Planungsrichtlinie bestimmen, welcher Thread soll erwirb den Mutex.

Diese Aussage besagt effektiv, dass die Implementierung frei ist, um den gewünschten Thread aufzuwecken.

für Linux kann jedoch die Planer Politik hier: http://man7.org/linux/man-pages/man7/sched.7.html

Beachten Sie, dass die Linux-man-Seite überhaupt nicht erwähnt mutexes macht.

Wenn Ihr Code von einer bestimmten Aktivierungsreihenfolge abhängt, ist ein einfacher Mutex das falsche zu verwendende Synchronisationsobjekt.

+0

Danke. Aber, in meiner Frage werden Thread 1 und Thread 2 nicht mehr durch Mutex blockiert. Sie sind in der Warteschlange und warten Thread 3 zu beenden. Mein Problem ist: nach Thread 1 Release der Mutex zu Thread 3, welche Position ist Thread 1 ersetzt in der Warteschlange (vor Thread 2 oder hinter Thread 2)? – bvp147