Entrambe le chiamate sono essenzialmente equivalenti sul moderno Linux:il primo approccio potrebbe essere utilizzato per accedere alla memoria condivisa POSIX da linguaggi come go (vedi https://github.com/fabiokung/shm/blob/master/shm_linux.go) dove la memoria condivisa POSIX no disponibile nativamente:potrebbe essere diverso per altri sistemi operativi/versioni in cui la prima chiamata porterebbe alla creazione di alcuni file o /dev/shm semplicemente non disponibile e/o forse prestazioni più lente. Le regole di unione dei percorsi potrebbero anche evolversi da una versione all'altra di librt
Il primo approccio chiamato API dei file mappati in memoria (supportato nelle librerie std)
2a chiamata API di memoria condivisa POSIX (richiede librt aka libposix su Linux come dipendenza Costruisce internamente il percorso e chiama open)
Dopo aver letto il sorgente di shm_open , posso dire che questi due metodi sono quasi gli stessi.
collegamento:https://code.woboq.org/userspace/glibc/sysdeps/posix/shm_open.c.html
shm_open aggiunge solo il prefisso shm_dir quindi invoca il normale open syscall, niente di speciale.
Se apri e mmap() un file normale, i dati finiranno in quel file.
Se hai solo bisogno di condividere una regione di memoria, senza la necessità di rendere persistenti i dati, il che comporta un ulteriore sovraccarico di I/O, usa shm_open().
Una tale regione di memoria ti permetterebbe anche di memorizzare altri tipi di oggetti come mutex o semafori, che non puoi memorizzare in un normale file con mmap() sulla maggior parte dei sistemi.