2012-04-09 5 views
5

Ich habe einen einfachen Brocken deterministischer Arbeit, der nur dreizehn Maschinenanweisungen benötigt, um abzuschließen. Da der erste Befehl einen selbstgebauten Semaphor (Spinlock) verwendet und der letzte Befehl ihn freigibt, bin ich sicher vor allen anderen Threads, die auf den anderen Kernen laufen, während sie versuchen, denselben Semaphor zu nehmen und zu geben.Wie kann ich die Vorbelegung meines Threads im Benutzermodus vermeiden?

Das Problem tritt auf, wenn ein Thread einen Thread unterbricht, der den Semaphor hält, bevor er seinen "kritischen Abschnitt" beenden kann. Im schlimmsten Fall tötet die Unterbrechung den Thread, während er den Semaphor hält oder wie es passieren kann, dass einer der Threads, der normalerweise um den Semaphor konkurriert, in Code verzweigt, der den Interrupt erzeugen kann, der einen Deadlock verursacht.

Ich habe keine Möglichkeit, mit diesen anderen Threads zu synchronisieren, wenn sie in die Teile des Codes verzweigen, die ich nicht kontrollieren kann. Ich denke, ich muss Interrupts deaktivieren, wie ich es in meinen alten VxWorks-Tagen gemacht habe, als ich im Kernel-Modus lief. Es sind immer dreizehn Anweisungen und ich bin immer vollkommen sicher, wenn ich alle dreizehn Anweisungen erledigen kann, bevor ich einen Interrupt einhalten muss. Oh, und es sind all meine eigenen internen Daten, andere, dass der hauseigene Semaphor nichts anderes ist, was irgendetwas anderes sperrt.

Ich habe mehrere Antworten gelesen, die meiner Meinung nach nahe sind. Die meisten haben mit Critical Section-Aufrufen der Windows-API zu tun (falsches Betriebssystem, aber vielleicht das richtige Konzept). Die meisten falschen Lösungen gehen davon aus, dass ich alle störenden Threads dazu bringen kann, einen Mutex zu verwenden, den ich mit den Pthread-Bibliotheken erstelle.

Ich brauche diese Lösung in C/C++ auf Linux und Solaris.

Johnny Crash Frage ist ganz in der Nähe prevent linux thread from being interrupted by scheduler

KermitG auch Can I prevent a Linux user space pthread yielding in critical code?

Vielen Dank für Ihre Aufmerksamkeit.

+3

Verwenden Sie Mutexe aus Ihrer Thread-Bibliothek (Pthread) und lesen Sie die Dokumentation sorgfältig. Implementieren Sie keine eigenen Synchronisationsprimitive. Parallele Programmierung ist schwer :) –

+1

@ RafałRawicki: "Tun Sie nichts, weil es schwer ist." Er muss vielleicht nur, weil Mutexe Mist sind. – Cartesius00

+0

möglich duplicate von [verhindern, dass linux thread vom scheduler unterbrochen wird] (http://stackoverflow.com/questions/2595735/prevent-linux-thread-from-being-interrupted-by-scheduler) –

Antwort

3

Sie können die Verhinderung eines Benutzermodus-Threads nicht verhindern. Kritische Abschnitte (und alle anderen Synchronisierungsobjekte) verhindern Kollisionen Ihrer Threads, verhindern jedoch keinesfalls, dass sie vom Betriebssystem unterlaufen werden.

Wenn andere Threads Zweig in etwas auf Timeout, während dieser etwas zu einem Deadlock führen kann - Sie haben ein Design-Problem.

Ein korrektes Design sollte am pessimistischsten sein: Vorurteile können überall für unbestimmte Zeit auftreten.

+0

Weitere Forschungen haben mich dazu geführt eingebaute atomare Funktionen, die von den Compilern bereitgestellt werden. Zum Beispiel GCC 4.7 Handbuch, Abschnitt 6.52 Adressen atomaren Operationen. Ich glaube, dass ich einen __atomic_thread_fence brauche, aber ich bin mir nicht sicher, ob das den Vorbeugungsschutz bietet, den ich brauche. – wapadomo

Verwandte Themen