linux – IPC共享内存和线程内存之间的性能差异

我经常听到,与访问线程之间的进程内存相比,访问进程之间的共享内存段没有性能损失.换句话说,多线程应用程序不会比使用共享内存的一组进程更快(不包括锁定或其他同步问题).

但我怀疑：

1)shmat()将本地进程虚拟内存映射到共享段.必须为每个共享存储器地址执行此转换,并且可能代表显着的成本.在多线程应用程序中,不需要额外的转换：所有VM地址都转换为物理地址,就像在不访问共享内存的常规进程中一样.

2)内核必须以某种方式维护共享内存段.例如,当连接到shm的所有进程都被删除时,shm段仍然处于运行状态,并且最终可以被新启动的进程重新访问.可能存在与shm段上的内核操作相关的一些开销.

多进程共享内存系统是否与多线程应用程序一样快？

解决方法:

1) shmat() maps the local process virtual memory to the shared
segment. This translation has to be performed for each shared memory
address and can represent a significant cost, relative to the number
of shm accesses. In a multi-threaded application there is no extra
translation required: all VM addresses are converted to physical
addresses, as in a regular process that does not access shared memory.

除了设置共享页面的初始成本之外,与常规内存访问相比没有开销 – 在调用shmat()的过程中填充页面表 – 在大多数Linux版本中,每4KB(1或8个字节)共享内存.

对于所有相关比较而言,无论页面是共享还是在同一进程内,都是相同的成本.

2) The shared memory segment must be maintained somehow by the kernel.
I do not know what that ‘somehow’ means in terms of performances, but
for example, when all processes attached to the shm are taken down,
the shm segment is still up and can be eventually re-accessed by newly
started processes. There must be at least some degree of overhead
related to the things the kernel needs to check during the lifetime of
the shm segment.

无论是否共享,每个内存页面都附有一个“结构页面”,其中包含有关该页面的一些数据.其中一项是参考计数.当页面被赋予进程[无论是通过“shmat”还是某种其他机制]时,引用计数递增.当通过某种方式释放它时,引用计数递减.如果递减的计数为零,则实际释放页面 – 否则“不再发生任何事情”.

与分配的任何其他内存相比,开销基本上为零.相同的机制用于页面的其他目的 – 例如你有一个内核也使用的页面 – 你的进程死了,内核需要知道不要释放该页面,直到它被内核发布为以及用户进程.

创建“fork”时会发生同样的事情.当一个进程被分叉时,父进程的整个页表基本上被复制到子进程中,所有页面都是只读的.无论何时发生写入,内核都会发生错误,导致该页面被复制 – 因此现在该页面有两个副本,执行写入的过程可以修改它的页面,而不会影响其他进程.一旦子(或父)进程终止,当然所有仍由BOTH进程拥有的页面[例如永远不会被编写的代码空间,可能是一堆从未被触及的常见数据等]显然不能直到两个进程都“死”为止.所以再次,引用计数页面在这里很有用,因为我们只计算每个页面上的引用计数,并且当ref-count为零时 – 也就是说,当使用该页面的所有进程都释放它时 – 页面是实际上作为“有用的页面”返回.

共享库完全相同.如果一个进程使用共享库,则该进程结束时将释放该进程.但是,如果两个,三个或100个进程使用相同的共享库,则代码显然必须保留在内存中,直到不再需要该页面为止.

所以,基本上,整个内核中的所有页面都已经被引用计数了.开销很小.

标签：multithreading,linux,ipc,shared-memory
来源： https://codeday.me/bug/20190930/1834975.html