Gemeinsame Mmap Koordination Fcntl Schlösser mit?

Question

Wenn für Shared-Memory mmap() (von Linux oder anderen Unix-ähnlichen Systemen) ist es möglich (und tragbar) zur Verwendung fcntl() (oder flock() oder lockf() Funktionen) zu koordinieren Zugriff auf die Mapping?

Die Reaktionen auf dieses SO Frage , dass es funktionieren sollte vorzuschlagen scheint.

Die Idee, die ich im Sinne habe, wäre das Shared Memory mit einer Prozess / Seite Karte strukturiert hat, um die Sperrkonflikte zu minimieren. Prozesse könnten jede Arbeit mit ihren Seiten gleichzeitig, und einer Sperre würde nur erworben werden, wenn die Prozess / Seite Zuordnungen zu aktualisieren. (Lesezugriff von unowned Seiten würde bedeuten, eine Seriennummer überprüft, das Kopieren der gewünschten Daten, dann die Validierung, dass die Seriennummer dieses Blocks nicht verändert hatte).

Konzeptionell jeder Prozess diese Datei Mapping teilen würde die mmap() ausführen, einen freien Block findet darin, erwerben eine Sperre für den Prozess / Seitenbereich, zu aktualisieren, die mit ihrer eigenen Zuordnung, die Sperre und dann weiter fröhlich mit seiner Arbeit. Jeder Prozess für veraltete Mappings suchen könnte (mit kill() mit Null als Signal) und den Prozess / Seite Tabellenzuordnung aufzuräumen.

(Grob, obs, ich bin liebäugle mit einem Producer / Consumer-Processing-Engine unter Verwendung von Shared Memory von Python über Linux, ich die Lösung tragbar sein möge BSD und andere Programmiersprachen --- so lange als Träger mmap() und die notwendigen Schnittstellen zu fcntl(), flock() oder lockf(). ich auch in psuedo-Code zeigt interessiert sein würde, wie ein Sperr-Konflikt messen würde und alle Synchronisierungsfehler erkennen. ich bin mir bewusst, dass die Threading und Multiprozessing mit ihren jeweiligen Queue() Objekte die einfachste Art und Weise sind ein Python-Producer / Consumer-Verarbeitungsmodell zu implementieren).

Answer 1

Ich bin sicher, dass die Sperren mutual exclusion bieten werden, aber ich weiß nicht, ob sie ihnen geben werden, eine Speicherbarriere. Es scheint, wie Springen in den Kernel (die fcntl, Herde und lockf tun wird) ist wahrscheinlich , etwas zu tun , dass Kräfte aus, um Speicher liest und schreibt zu begehen, aber ich bezweifle, werden Sie eine bekommen Fest Garantie. Ich denke, das eines der Dinge ist, wo es funktioniert wahrscheinlich, und Prüfung wird zeigen, dass es funktioniert, aber Sie werden nicht wissen, dass es funktioniert immer, wenn Sie einen Verweis finden so viel zu sagen.

Ich habe etwas ähnliches wie dies von C getan, aber ich verwenden Atom spinlocks in dem gemeinsamen genutzten Speicher selbst. Früher ist es so, dass Sie Montag ein wenig inline zu tun hatten, aber gcc hat nun einige intrinsischen Operationen, die Sie verwenden können:

http://gcc.gnu.org/onlinedocs/gcc/Atomic- Builtins.html

Wenn Sie bereit sind, eine sehr einfache Python-Erweiterung zu schreiben, könnten Sie __sync_lock_test_and_set wickeln (...) und __sync_lock_release (...) zu tun, was Sie brauchen. Diese sollten ziemlich tragbar sein.

Ich glaube, es gibt einen Weg zu Pthread mutexes in der gemeinsamen Speicher zu setzen, aber ich habe keine Erfahrung damit. Auch hier würden Sie eine einfache C-Erweiterung schreiben müssen, um Zugriff auf dem von Python zu bekommen.