Beide Aufrufe sind auf modernem Linux im Wesentlichen äquivalent. Der erste Ansatz könnte verwendet werden, um auf POSIX-Shared-Memory von Sprachen wie go (siehe https://github.com/fabiokung/shm/blob/master/shm_linux.go) zuzugreifen, wo POSIX-Shared-Memory nicht nativ verfügbar - es könnte für andere Betriebssysteme/Versionen anders sein, wo der erste Aufruf zu einer Dateierstellung führen würde oder /dev/shm einfach nicht verfügbar und/oder möglicherweise langsamer ist. Regeln für das Zusammenführen von Pfaden könnten sich auch von Version zu Version von librt weiterentwickeln
1. Ansatz namens Memory Mapped Files API (unterstützt in Standardbibliotheken)
2. aufgerufene POSIX-Shared-Memory-API (erfordert librt aka libposix unter Linux als Abhängigkeit. Es baut intern den Pfad auf und ruft open auf)
Nach dem Lesen der Quelle von shm_open , kann ich sagen, dass diese beiden Methoden fast gleich sind.
Link:https://code.woboq.org/userspace/glibc/sysdeps/posix/shm_open.c.html
shm_open fügt einfach das Präfix shm_dir hinzu und ruft dann den normalen open auf Systemaufruf, nichts Besonderes.
Wenn Sie eine normale Datei öffnen und mmap() verwenden, landen die Daten in dieser Datei.
Wenn Sie nur einen Speicherbereich gemeinsam nutzen müssen, ohne die Daten persistieren zu müssen, was zusätzlichen I/O-Overhead verursacht, verwenden Sie shm_open().
Ein solcher Speicherbereich würde Ihnen auch erlauben, andere Arten von Objekten wie Mutexe oder Semaphore zu speichern, die Sie auf den meisten Systemen nicht in einer regulären mmap()-Datei speichern können.