Kar*_*uil 2 c linux posix shared-memory
通常,共享内存是使用映射到进程地址空间的部分On-Disk文件实现的.每当在共享区域上发生内存访问时,文件系统就会在磁盘上写入更改,这是一个很大的开销.
通常,调用fopen()返回传递给mmap()的文件描述符以创建文件的内存映射.shm_open显然,工作方式相同.它返回它甚至可以与普通的文件操作(例如,使用的文件描述符ftruncate,ftell,fseek...等).我们指定一个字符串作为参数shm_open但不像fopen(),它不是可见文件系统上的真实文件的名称(已安装的HDD,闪存驱动器,SSD等).完全不相关的进程可以使用相同的字符串名称将相同的区域映射到其地址空间.
那么,传递给shm_open什么shm_open创建/打开的字符串参数是什么？它是一个临时文件系统(/ tmp)上的文件,最终被许多进程用来创建共享区域(嗯,我认为它必须是某种文件,因为它返回文件描述符)？或者它是由内核支持的某种神秘且隐藏的文件系统？
人们说shm_open比较快,fopen因为没有磁盘操作,所以我建议的理论是内核使用一个不可见的基于RAM的文件系统来实现共享内存shm_open!
通常，共享内存是使用部分映射到进程地址空间的磁盘文件来实现的。
这通常是错误的，至少在运行最新Linux发行版的台式机或笔记本电脑上具有一定数量的RAM（例如，至少8Gbytes）。
因此，磁盘不相关。您可以使用shm_open而无需任何交换。请参见shm_overview（7），注意/dev/shm/通常是tmpfs挂载的文件系统，因此请勿使用任何磁盘。参见tmpfs（5）。并且tmpfs不要使用该磁盘（除非您达到崩溃状态，这不太可能发生），因为它可以在虚拟内存中使用。
文件系统涉及将更改写入磁盘，这是很大的开销。
这通常是错误的。在大多数系统上，最近写入的文件都在页面缓存中，而页面缓存无法快速到达磁盘（顺便说一句，这就是为什么关闭过程需要调用sync（2），否则很少使用它的原因...）。
顺便说一句，在大多数台式机和笔记本电脑上，很容易观察到。硬盘上有一些LED，使用shm_open和相关呼叫时您不会看到它闪烁。顺便说一句，您还可以使用proc（5）（尤其是/proc/diskstatsetc ....）来查询内核有关其磁盘活动的信息。
通常,共享内存是使用映射到进程地址空间的部分On-Disk文件实现的.每当在共享区域上发生内存访问时,文件系统就会在磁盘上写入更改,这是一个很大的开销.
这似乎相当冒昧,并不完全正确.基本上所有实现共享内存区域的机器(在IPC意义上)都具有虚拟内存单元,通过它们支持该功能.可能有也可能没有任何持久存储支持任何特定的共享内存段或其任何部分.只有被分页的部分(如果有的话)才需要由此类存储支持.
shm_open显然,工作方式相同.它返回它甚至可以与普通的文件操作(例如,使用的文件描述符ftruncate,ftell,fseek...等).
它shm_open()具有一个open()以其为模型的接口,并且它返回一个可以有意义地与某些通用I/O函数一起使用的文件描述符,并不意味着shm_open()在任何更广泛的意义上"以相同的方式工作".几乎所有系统资源都表示为进程作为文件.这提供了一个更简单的整体系统接口,但它并不意味着潜在资源的任何共性,除了它们可以通过相同的功能操作 - 实际上它们可以.
那么,传递给
shm_open什么shm_open创建/打开的字符串参数是什么？
该参数是标识共享内存段的字符串.你已经知道了,但你似乎认为它还有更多.至少没有shm_open指定接口的级别(POSIX).标识符主要对内核有意义.不同的实现以不同方式处理细节
它是某个临时文件系统(/ tmp)上的文件,最终由许多进程用来创建共享区域
可能是,但可能不是.为其提供的任何文件系统接口很可能(但不确定)是虚拟文件系统,而不是磁盘上的实际可访问文件.持久存储(如果使用)可能是在系统的交换空间之外提供的.
(嗯,我认为它必须是某种文件,因为它返回一个文件描述符)？
这样的结论是没有根据的.套接字和管道也通过文件描述符表示,但它们没有相应的可访问文件.
或者它是由内核支持的某种神秘且隐藏的文件系统？
这可能是一个更好的概念,但同样,可能根本没有任何持久存储.然而,在某种程度上,它可能是系统交换空间的一部分,这并不是那么神秘.