Alternative zu SysV Semaphoren

[Kamikaze]

Wenn ich ipcs aufrufe werden immer einige Shared-Memories gelistet aber abgesehen von meinen eigenen Semaphoren keine. Also frage ich mich was für ein Locking-Mechanismus denn üblicherweise verwendet wird?

Für Posix-Semaphore müsste ich erst ein Kernel-Modul laden, aber etwas anderes fällt mir eigentlich nicht ein. Irgendeine Form von Locking muss es doch eigentlich für jeden Shared Memory geben.

 

[Vincent Vega]

Wenn ich ipcs aufrufe werden immer einige Shared-Memories gelistet aber abgesehen von meinen eigenen Semaphoren keine. Also frage ich mich was für ein Locking-Mechanismus denn üblicherweise verwendet wird?

Für IPC mit Hilfe von Shared Memory werden üblicherweise Semaphore verwendet. Da Shared Memory dafür sorgt, dass sich mehrere Prozesse eine Backing Resource (phys. Speicher, ausgelagerte Seite, etc.) teilen, kann man aber auch problemlos ein eigenes Locking implementieren. Ist aber nicht schön und vermutlich auch nicht im Sinne des Erfinders.

Für Posix-Semaphore müsste ich erst ein Kernel-Modul laden, aber etwas anderes fällt mir eigentlich nicht ein. Irgendeine Form von Locking muss es doch eigentlich für jeden Shared Memory geben.

Nein, warum? Wenn Du anderweitig sicherstellst, dass es keine konkurrierenden Zugriffe gibt, z.B. mit Signalen, dann brauchst Du kein Locking.

 

[Kamikaze]

Ja, an Signale hatte ich nicht gedacht. Ich habe Semaphore immer für die etablierte Standardlösung gehalten aber ich scheine der Einzige zu sein, der die verwendet.

 

[GaTh3N]

Hätte ich auch gedacht, dass Semaphoren häufiger verwendet werden. In der englischen Wikipedia steht was recht interessantes dazu.

 

[rMarkus]

An der Stelle würde mich mal interessieren, wie Du Semaphore im Shared-RAM implemtiert hast.

 

[Kamikaze]

Den Pointer auf das SHM caste ich auf einen Struct. Das Struct enthält unter anderem einen int mit der Semaphore ID. Da diese sich nie ändert dürfen alle Prozesse auf diese jederzeit zugreifen. Den Rest des Structs fassen sie allerdings nur an wenn sie die Ressource vom Semaphor bekommen.

 

[rMarkus]

etwa so:

while (semaphor_belegt)
    sleep ( 1);
semaphor_belegt= true;

 

[Kamikaze]

etwa so:

while (semaphor_belegt)
    sleep ( 1);
semaphor_belegt= true;

Was'n das für'n Käse? Du kannst eine Semaphor nicht selbst belegen, dass muss der Kernel machen.

 

[xbit]

Naja, Du musst die Semaphore schon inkrementieren oder dekrementieren. Allerdings gibt's dafuer ja Funktionen. Und ich sehe den Code Schnippsel auch eher als Pseudo Code.

 

[Kamikaze]

Die Funktionen bitten den Kernel darum das zu tun. Und das

while (semaphor_belegt)
    sleep ( 1);

ist auch als Pseudocode grob falsch. In Wirklichkeit teil der Prozess dem Kernel mit er will doch bitte den Semaphor verringern (Resource belegen). Der Prozess wird dann vollkommen schlafen gelegt (zumindest der entsprechende Thread) und vom Kernel erst dann wieder geweckt, bis der Semaphor verringert wurde. Man kann das auch über Polling machen, aber das verringern des Semaphors macht trotzdem der Kernel und wenn man nichts besseres zu tun hat und dann nochmal zu pollen sollte man gleich dem Kernel das Wecken überlassen.

 

[xbit]

Soweit ich weiss, kann man auch ueber ein Flag steuern, dass der Prozess nicht blockiert, wenn er die Semaphore verringern will.

OK, Du hast Recht, der Pseudocode ist nicht korrekt.

Um auf Deine urspruengliche Frage zurueckzukommen. Du koenntest den Zugriff auf das Shared Memory auch anderweitig regeln. Pipes oder Messages Queues koennte man auch verwenden, so dass beispielsweise immer abwechselnd auf das Shared Memory zugegriffen werden darf.

Auf der anderen Seite ist auch fraglich, ob immer nur einer exklusiv Zugriff auf den Bereich haben darf. Eventuell koennte man sich auch einen Zugriff ueberlegen, bei dem keine Sperren vorhanden sein muessen.

 

[rMarkus]

[ ] Der eigentliche Fehler in meinem Pseudocode wurde nicht erkannt
[x] Es wurde viel aggressive heisse Luft zur Selbstdarstellung von "Coding Skillz" erzeugt

 

[Vincent Vega]

Was'n das für'n Käse? Du kannst eine Semaphor nicht selbst belegen, dass muss der Kernel machen.

Der Punkt ist, dass Du für's implementieren eines Locks einen nicht-unterbrechbaren Read-Update-Write Cycle brauchst.

 

[rMarkus]

korrekt

 

[Kamikaze]

Der Punkt ist, dass Du für's implementieren eines Locks einen nicht-unterbrechbaren Read-Update-Write Cycle brauchst.

Und das darf unter einem modernen System (abgesehen von Windows) nur der Kernel. Jedenfalls hoffe ich das.

 

[Vincent Vega]

Und das darf unter einem modernen System (abgesehen von Windows) nur der Kernel. Jedenfalls hoffe ich das.

Jein, wenn Du ein paar Annahmen treffen kannst, dann kannst Du das ohne weiteres auch in einem Userprogramm hinkriegen. Am einfachsten ist es, wenn die CPU eine entsprechende Instruktion bereit stellt, denn eine einzelne Instruktion ist immer atomar -- unabhängig von der Anzahl der CPUs.

 

[Kamikaze]

Wie soll eine Instruktion in einer Multi-Core Architektur atomar sein? Werden dann alle anderen Cores gestoppt? Das widerspricht allem was ich zu dem Thema weiß.

 

[Vincent Vega]

Wie soll eine Instruktion in einer Multi-Core Architektur atomar sein? Werden dann alle anderen Cores gestoppt? Das widerspricht allem was ich zu dem Thema weiß.

Eine Instruktion ist immer atomar, d.h. nicht unterbrechbar. Nicht einmal ein Interrupt unterbricht die Ausführung einer einzelnen Instruktion. Da eine Instruktion auch bei mehreren CPUs immer nur auf einem Kern ausgeführt wird, ergibt sich an der Stelle auch keine Änderung.

Was Du vermutlich meinst ist, warum es beim Verwenden einer einzelnen Instruktion keine konkurrierenden Zugriffe auf z.B. Speicherressourcen gibt. Aber auch das ist einfach zu erklären: Schließlich gibt es bei SMP Architekturen immer nur einen Address- u. Datenbus zum Speicher hin. Die CPUs handeln untereinander per Hardware-Protokoll aus welche CPU exklusiven Zugriff bekommt. Wie das im Detail funktioniert ist von CPU zu CPU unterschiedlich und steht im entsprechenden Manual.