Gemeinsamer Speicher

Qt bietet zwei Techniken, um Speicher mit anderen Prozessen im selben System gemeinsam zu nutzen: „ QSharedMemory “ und speicherabgebildete Dateien unter Verwendung von „ QFile “. Speicher, der mit anderen Prozessen gemeinsam genutzt wird, wird oft als „Segment“ bezeichnet, und obwohl dies in der Vergangenheit auf Prozessoren mit segmentierten Speichermodellen möglicherweise als spezifische Segmente implementiert wurde, ist dies in keinem modernen Betriebssystem mehr der Fall. Gemeinsam genutzte Speichersegmente sind einfach Speicherbereiche, für die das Betriebssystem sicherstellt, dass sie allen beteiligten Prozessen zur Verfügung stehen.

Gemeinsame Speichernutzung mit QSharedMemory

QSharedMemory bietet eine einfache API, um ein Shared-Memory-Segment einer bestimmten Größe zu erstellen oder sich an eines anzuschließen, das von einem anderen Prozess erstellt wurde. Zusätzlich stellt sie zwei Methoden zur Verfügung, um das gesamte Segment mit „ lock “ und „ unlock “ zu sperren bzw. freizugeben, wobei ein internes „ QSystemSemaphore “ verwendet wird.

Gemeinsam genutzte Speichersegmente und System-Semaphoren werden im System global durch einen „Schlüssel“ identifiziert, der in Qt durch die Klasse ` QNativeIpcKey ` repräsentiert wird. Je nach Betriebssystem unterstützt Qt zudem möglicherweise mehrere verschiedene Backends für die gemeinsame Speichernutzung; weitere Informationen und Einschränkungen finden Sie in der Dokumentation zu „Native IPC Keys “.

QSharedMemory ist darauf ausgelegt, Speicher nur innerhalb derselben Berechtigungsstufe gemeinsam zu nutzen (d. h. nicht mit nicht vertrauenswürdigen anderen Prozessen, wie z. B. solchen, die von anderen Benutzern gestartet wurden). Bei Backends, die dies unterstützen, erstellt „ QSharedMemory “ Segmente so, dass sich nur Prozesse mit derselben Berechtigungsstufe daran anhängen können.

Speicherfreigabe über speicherabgebildete Dateien

Die meisten Dateien können mithilfe von ` QFile::map()` in den Speicher abgebildet werden, und sofern die Option ` MapPrivateOption ` nicht angegeben ist, werden alle Schreibvorgänge in das abgebildete Segment von allen anderen Prozessen beobachtet, die dieselbe Datei abgebildet haben. Ausnahmen bei Dateien, die in den Speicher abgebildet werden können, sind unter anderem Remote-Dateien in Netzwerkfreigaben oder solche, die sich in bestimmten Dateisystemen befinden. Selbst wenn das Betriebssystem das Mappen von Remote-Dateien in den Speicher zulässt, werden E/A-Operationen an der Datei wahrscheinlich zwischengespeichert und verzögert, was eine echte gemeinsame Speichernutzung unmöglich macht.

Diese Lösung hat den großen Vorteil, dass sie unabhängig von jeglicher Backend-API ist und sich einfacher mit Nicht-Qt-Anwendungen zusammenarbeiten lässt. Da „ QTemporaryFile “ ein „ QFile “ ist, können Anwendungen diese Klasse nutzen, um eine Bereinigungssemantik zu erreichen und zudem eindeutige Shared-Memory-Segmente zu erstellen.

Um eine Sperrung des gemeinsam genutzten Speichersegments zu erreichen, müssen Anwendungen eigene Mechanismen einsetzen. Eine Möglichkeit besteht darin, ` QLockFile` zu verwenden. Eine andere und weniger aufwendige Lösung ist die Verwendung von ` QAtomicInteger ` oder ` std::atomic ` an einem vorab festgelegten Offset innerhalb des Segments selbst. Auf einigen Betriebssystemen stehen möglicherweise übergeordnete Sperrprimitive zur Verfügung; unter Linux können Anwendungen beispielsweise das „pshared“-Flag im Mutex-Attribut setzen, das an ` pthread_mutex_create() ` übergeben wird, um anzugeben, dass sich der Mutex in einem Shared-Memory-Segment befindet.

Beachten Sie, dass das Betriebssystem wahrscheinlich versuchen wird, alle Schreibvorgänge in den gemeinsam genutzten Speicher dauerhaft zu speichern. Dies kann erwünscht sein oder zu Leistungseinbußen führen, wenn die Datei selbst nur vorübergehend gedacht war. In diesem Fall sollten Anwendungen ein RAM-gestütztes Dateisystem verwenden, wie beispielsweise „ tmpfs “ unter Linux (siehe QStorageInfo::fileSystemType()), oder ein Flag an die native Funktion zum Öffnen von Dateien übergeben, um das Betriebssystem anzuweisen, das Speichern des Inhalts auf dem Speichermedium zu vermeiden.

Es ist möglich, dateibasierten Shared Memory für die Kommunikation mit nicht vertrauenswürdigen Prozessen zu nutzen; in diesem Fall sollte die Anwendung jedoch größte Vorsicht walten lassen. Die Dateien können gekürzt oder verkleinert werden und dazu führen, dass Anwendungen, die auf Speicherbereich jenseits der Dateigröße zugreifen, abstürzen.

Linux-Hinweise zu speicherabgebildeten Dateien

Auf modernen Linux-Systemen ist das Verzeichnis ` /tmp ` zwar häufig ein ` tmpfs `-Einhängepunkt, dies ist jedoch keine zwingende Voraussetzung. Das Verzeichnis ` /dev/shm ` muss hingegen ein ` tmpfs ` sein und dient ausschließlich dem Zweck der Speicherfreigabe. Beachten Sie, dass es für alle les- und schreibbar ist (wie ` /tmp ` und ` /var/tmp`), sodass Anwendungen vorsichtig mit den dort offengelegten Inhalten umgehen müssen. Eine weitere Alternative ist die Verwendung des XDG-Laufzeitverzeichnisses (siehe QStandardPaths::writableLocation() und QStandardPaths::RuntimeLocation), das auf Linux-Systemen mit systemd ein benutzerspezifisches Verzeichnis ist: tmpfs.

Eine noch sicherere Lösung besteht darin, ein „memfd“ mithilfe von memfd_create(2) zu erstellen und den Dateideskriptor über die Interprozesskommunikation zu übergeben, beispielsweise wie unter QDBusUnixFileDescriptor beschrieben oder indem der Kindprozess eines QProcess diesen erbt. „memfds“ können zudem gegen eine Verkleinerung versiegelt werden, sodass sie sicher bei der Kommunikation mit Prozessen mit einer anderen Berechtigungsstufe verwendet werden können.

Hinweise zu speicherabgebildeten Dateien unter FreeBSD

FreeBSD verfügt ebenfalls über „ memfd_create(2) “ und kann Dateideskriptoren mithilfe derselben Techniken wie Linux an andere Prozesse übergeben. Es gibt keine standardmäßig eingebundenen temporären Dateisysteme.

Windows-Hinweise zu speicherabgebildeten Dateien

Unter Windows kann die Anwendung das Betriebssystem anweisen, den Inhalt der Datei nicht auf einem permanenten Speichermedium zu speichern. Diese Anweisung erfolgt durch Übergabe des Flags „ FILE_ATTRIBUTE_TEMPORARY “ im Parameter „ dwFlagsAndAttributes “ an die Win32-Funktion „ CreateFile “, des Flags „ _O_SHORT_LIVED “ an die Low-Level-Funktion „ _open() “ oder durch Einfügen des Modifikators „T“ in die C-Laufzeitfunktion „ fopen() “.

Es gibt außerdem ein Flag, das das Betriebssystem anweist, die Datei zu löschen, sobald das letzte Handle zu ihr geschlossen wird (FILE_FLAG_DELETE_ON_CLOSE, _O_TEMPORARY und der Modifikator „D“), aber beachten Sie, dass sich alle Prozesse, die versuchen, die Datei zu öffnen, darüber einig sein müssen, ob dieses Flag verwendet wird oder nicht. Eine Nichtübereinstimmung führt wahrscheinlich zu einer Zugriffsverletzung und dazu, dass die Datei nicht geöffnet werden kann.