Les deux appels sont essentiellement équivalents sur Linux moderne - la 1ère approche pourrait être utilisée pour accéder à la mémoire partagée POSIX à partir de langages comme go (voir https://github.com/fabiokung/shm/blob/master/shm_linux.go) où la mémoire partagée POSIX n'est pas disponible nativement - cela peut être différent pour d'autres systèmes d'exploitation/versions où le 1er appel entraînerait la création de fichiers ou /dev/shm n'est tout simplement pas disponible et/ou peut-être des performances plus lentes. Les règles de fusion de chemins peuvent également évoluer d'une version à l'autre de librt
1ère approche appelée API de fichiers mappés en mémoire (prise en charge dans les bibliothèques std)
2ème API de mémoire partagée POSIX appelée (nécessite librt alias libposix sous Linux comme dépendance Il construit en interne le chemin et appelle open)
Après avoir lu le source de shm_open , je peux dire que ces deux méthodes sont presque identiques.
lien :https://code.woboq.org/userspace/glibc/sysdeps/posix/shm_open.c.html
shm_open ajoute simplement le préfixe shm_dir puis invoque le open normal appel système, rien de spécial.
Si vous ouvrez et mmap() un fichier normal, les données se retrouveront dans ce fichier.
Si vous avez juste besoin de partager une région mémoire, sans avoir besoin de conserver les données, ce qui entraîne une surcharge d'E/S supplémentaire, utilisez shm_open().
Une telle région de mémoire vous permettrait également de stocker d'autres types d'objets tels que des mutex ou des sémaphores, que vous ne pouvez pas stocker dans un fichier standard mmap() sur la plupart des systèmes.