Benötigen Semaphore syscalls?

Question

Ich bereite mich auf eine Prüfung in Bezug auf Betriebssysteme vor, indem ich frühere Prüfungen mache. Es geht hauptsächlich um Unix-Systeme, die C-Programmiersprache, und es wird oft auf POSIX eingegangen, daher ist es wahrscheinlich am besten, diese Frage hier zu stellen.

Das Problem ist:

Geben Sie drei Nachteile von einfachen spinlocks und/oder Semaphore. Erklären Sie, wie der jeweils andere Mechanismus das Problem verbessert.

Einer der Nachteile gegeben 3 + Erklärung ist folgende:

Semaphores erfordern einen Systemaufruf, selbst wenn der Faden sofort erfolgen kann. (0.5 P) Spinlocks hingegen können komplett im Userspace implementiert werden und benötigen keine Systemaufrufe. Sie sind sehr effizient für kurze Wartezeiten. (0.5 P)

Warum sollten Semaphore syscalls erfordern? Müssen sie im Kernel-Bereich sein? Müssen sie privilegierte Anweisungen ausführen?

Sowohl Single-Prozessor- als auch Multi-Prozessor-Systeme müssen berücksichtigt werden.

Answer 1

Ein historischer Kontext wird die Dinge klarer machen. Semaphore waren ursprünglich Teil des systeminternen Interprozesskommunikationspakets (System V IPC), bevor POSIX IPC eine Sache war. Die Namen geben Ihnen wahrscheinlich einen Hinweis darauf, wohin die Dinge gehen; Der ursprüngliche Anwendungsfall war Sperren, die von kooperierenden Prozessen gemeinsam genutzt wurden. (Ich bin 99,99% Prozent sicher, IPC vor Threads um eine ganze Weile.)

POSIX Semaphore arbeiten mit Prozessen oder Threads, daher die Betriebssystem-Beteiligung. Der Kontext ist hier wichtig, weil die Antwort eindeutig auf der Standard-Semaphor-Implementierung und nicht auf dem abstrakten Konzept eines Semaphors beruht.

Answer 2

Ja, Semaphoren erfordern Systemaufrufe, außer in sehr speziellen Szenarien. Ein Semaphor muss warten können, bis die anderen Teilnehmer die Ressource freigegeben haben. Warten erfordert einen Systemaufruf.

Wenn die Anwärter auf die Sperre Zugriff auf einen gemeinsamen Speicherbereich haben und sich gegenseitig vertrauen, das Semaphor-Protokoll zu respektieren, was meist der Fall ist, wenn die Sperre zwischen Threads desselben Prozesses liegt, dann nicht benötigen immer einen Systemaufruf: Sie können unprivilegierte Prozessorbefehle verwenden, um den Sperrstatus zu prüfen und zu ändern. Dies ermöglicht es, das Schloss zu erhalten, wenn es frei ist, und das Schloss zu lösen, aber darauf zu warten, dass das Schloss frei ist, ist eine andere Sache.

Ein Spinlock bleibt beschäftigt ("dreht"), bis die Sperre frei wird. Wenn bekannt ist, dass die Threads, die um die Sperre konkurrieren, auf verschiedenen CPUs ausgeführt werden, kann dies eine gültige Strategie sein. Wenn die Threads möglicherweise auf derselben CPU ausgeführt werden, muss der Thread, der auf die Sperre wartet, zulassen, dass der andere Thread ausgeführt wird. Daher muss er ausgeführt werden. Bei Userland-Threads kann dies ohne Systemaufruf erfolgen.

Ein Semaphor soll schlafen, bis das Schloss fertig ist. In der realen Welt ist Schlafen durch Spinnen selten akzeptabel. Sleeping erfordert fast immer einen Systemaufruf: Der Kernel verschiebt den wartenden Thread aus der Ready-Liste des Schedulers in die Warteliste für das Semaphor-Objekt.