2016-03-26 14 views
1

Systemaufrufe in UNIX-ähnlichen Betriebssystemen sind reentrant (d. H. Mehrere Systemaufrufe können parallel ausgeführt werden). Gibt es bei diesen Systemaufrufen im Sinne der C/C++ 11 has-before-relation Ordnungsbeschränkungen?Bestellspezifikation für UNIX-Systemaufrufe

Zum Beispiel wollen wir das folgende Programm mit 3 Fäden betrachten (in Pseudocode):

// thread 1 
store x 1 
store y 2 

// thread 2 
store y 1 
store x 2 

// thread 3 
Thread.join(1 and 2) 
wait((load x) == 1 && (load y) == 1) 

sei hier angenommen, x und y gemeinsamen Standorte und alle load und store s haben die entspannte Ordnung . (HINWEIS: Bei entspannten atomaren Zugriffen werden Rassen nicht als Fehler betrachtet; sie sind intentional im Sinne von C/C++ 11-Semantik.) Dieses Programm kann terminieren, da (1) der Compiler store x 1 und store y 2 und dann neu anordnen kann (2) Führe store y 2, store y 1, store x 2 und dann store x 1 aus, so dass Thread 3 gleichzeitig x = 1 und y = 1 lesen kann.

Ich würde gerne wissen, ob das folgende Programm auch beendet werden kann. Hierbei nennt einige System syscall1() & syscall2() eingeführt sind in das Gewinde & 1 bzw. 2:

// thread 1 
store x 1 
syscall1() 
store y 2 

// thread 2 
store y 1 
syscall2() 
store x 2 

// thread 3 
Thread.join(1 and 2) 
wait((load x) == 1 && (load y) == 1) 

Das Programm scheint unmöglich zu beenden. In Ermangelung der Ordnungsbeschränkungen der aufgerufenen Systemaufrufe denke ich jedoch, dass dieses Programm möglicherweise beendet wird. Hier ist der Grund. Angenommen, syscall1() und syscall2() sind nicht serialisiert und können parallel ausgeführt werden. Dann kann der Compiler in voller Kenntnis der Semantik von syscall1() und syscall2() noch store x 1 & syscall1() und store y 2 nachbestellen.

Also möchte ich fragen, ob es Ordnungsbeschränkungen der Systemaufrufe gibt, die von verschiedenen Threads aufgerufen werden. Wenn möglich, würde ich gerne die maßgebliche Quelle für diese Art von Fragen wissen.

+0

Hier kommen Mutexe, Semaphore ins Spiel. Was Sie beschrieben haben, ist eine Race Condition.Systemaufrufe werden, wie dokumentiert, als threadsicher markiert, aber nicht alle von ihnen. Der Umgang mit Threads obliegt dem Programmierer, nicht dem System selbst! Buggy Threading-Apps ist ein Rezept für das Szenario der Rennbedingungen. – t0mm13b

+0

Die C/C++ 11-Semantik erlaubt Race-Bedingungen an atomaren Orten mit den entspannten Ordnungen. Im Wesentlichen möchte ich die Semantik von entspannten atomaren Zugriffen mit möglicherweise "gutartigen" Race Conditions und Systemaufrufen. –

Antwort

1

A system call (diejenigen, die in syscalls(2) ...) ist ein elementarer Betrieb, aus der Sicht eines Anwendungsprogrammes in Benutzer Land.

Jeder Systemaufruf ist (per Definition) Aufruf die Kernel, durch irgendeinen einzigenmachine code Befehl (SYSENTER, SYSCALL, INT ...); Details hängen vom Prozessor ab (dessen instruction set) und der ABI. Die kernel erledigt es (von der Verarbeitung Ihres Systemaufrufs - die erfolgreich oder fehlschlagen könnte), aber Ihr Benutzerprogramm sieht nur einen elementaren Schritt. Manchmal kann dieser Schritt (während dessen die Steuerung dem Kernel gegeben wird) ein langes Stück Zeit () dauern (z. B. Minuten oder Stunden).

So Ihr Programm in user land läuft auf einer niedrigen Pegel der virtuellen Maschine durch die user mode Maschine Anweisungen Ihres Prozessors durch eine einzige „virtuelle“ System-Aufruf-Instruktion (in der Lage zu tun, jeden Systemaufruf vom Kernel implementiert) ergänzt.

Dies verbietet nicht, dass Ihr Programm wegen der Rennbedingungen fehlerhaft ist.

Verwandte Themen