我需要在共享内存对象上使用shm_unlink吗？ [英] Do I need to use shm_unlink on a shared memory object?

问题描述

我编写了一个不断运行的服务器（GNU C ++ / Linux），偶尔执行小型独立程序来工作。为了有效地获取工作程序的数据，服务器创建并映射共享内存对象（代码为了清晰起见简写）：

  int fd = shm_open（/ shm_file，O_CREAT | O_TRUNC | O_RDWR，S_IRUSR | S_IWUSR）; 
 ftruncate（...）; 
 data = mmap（...）; 
 // etc ... 
 launchWorker（...）; //启动工作程序
  

然后，工作程序以类似的方式打开此共享内存 - 只有没有O_CREAT和O_TRUNC，即我们假设它已经存在）。

当工作完成后，它会关闭文件描述符，使用munmap（...）取消映射，并使用shm_unlink（...）取消链接。

此时，有一个文件/ dev / shm / shm_file，我猜是共享内存对象。在工作程序中取消链接不会删除它，因为服务器仍然打开它。当服务器取消链接时，文件系统对象将消失。此行为与shm_open / shm_unlink的手册页一致，并且适用于我的服务器/工作线程。

但是，现在我希望工人能够在它们之间共享某些数据，并且可能（为了测试）在服务器不运行时执行此操作。

如果我在一个工作程序中创建一个共享内存对象，并且退出时不要使用munmap（...）和shm_unlink（...），我注意到共享内存对象保留在/ dev / shm中，我可以在另一个工作程序中再次打开它。这很方便。

但是，这样做是否安全呢？ （即重复运行映射共享内存的程序，然后不解除映射/解除链接）？我猜unmap（）没有关系，因为内存映射会随着进程而消失，但是shm_unlink呢？鉴于操作系统决定何时删除对象，基于它是否仍在使用，如果我没有每次调用shm_unlink（），这将导致某种泄漏？

解决方案

唯一的漏洞是，文件将保留，即使在打开它的最后一个进程存在。
$ b

但是，因为这是在这种情况下的意图，它不是真的这样的泄漏。

/ dev / shm 的行为与普通文件一样（因为它们是）。

这意味着名称可以删除c $ c> unlink 或 shm_unlink ），但文件数据将保留，直到名称消失，并且使用它的最后一个进程停止这样做该文件打开或其内容 mmap ：ed计为使用它。）

但只有一个文件，无论多少次你打开和/或mmap它。

当一个进程退出所有打开的文件描述符被关闭，并删除所有内存映射。 p>

I've written a server (GNU C++ / Linux) which runs continuously, and occasionally executes small stand-alone programs to do work. In order to efficiently get data to the worker programs, the server creates and maps a shared memory object (code abbreviated for clarity):

int fd = shm_open("/shm_file", O_CREAT | O_TRUNC | O_RDWR, S_IRUSR | S_IWUSR);
ftruncate(...);
data = mmap(...);
// etc...
launchWorker(...);   // Start the worker program

The worker program then opens this shared memory in a similar way (except read-only, without the O_CREAT and O_TRUNC, i.e. we assume it already exists).

When the worker finishes, it closes the file descriptor, unmaps with munmap(...) and unlinks with shm_unlink(...).

At this point, there is a file "/dev/shm/shm_file" which I guess is the shared memory object. Unlinking in the worker doesn't remove it because the server still has it open. When the server unlinks it, the file system object disappears. This behavior is consistent with the man page for shm_open / shm_unlink, and works fine for my server/worker case.

However, now I'd like the workers to be able to share certain data between themselves, and possibly (for testing) do this when the server is not running.

If I create a shared memory object in one worker program and DO NOT use munmap(...) and shm_unlink(...) when it exits, I note that the shared memory object remains in /dev/shm, and I can open it again in another worker program. This is handy.

However, is it safe to do this? (i.e. repeatedly run a program which maps shared memory, then doesn't unmap/unlink it)? I'm guessing that the unmap() doesn't matter as the memory mapping will vanish with the process, but what about the shm_unlink? Given that the OS decided when to delete the object based on whether it is still being used, if I fail to call shm_unlink() every time, will this cause a leak of some kind?

解决方案

The only leak is that the file will stay even after the last process that opened it exists.

But since that was the intent in this case it is not really a leak as such.

The files in /dev/shm behave just like regular files (because they are).

This means that the name can be removed (using unlink or shm_unlink) but the file data will remain until the name is gone and the last process using it stops doing so (having the file open or it's content mmap:ed counts as using it).

But there is only the one file, no matter how many times you open and/or mmap it.

And when a process exits all open file descriptors are closed, and all memory mappings are removed.

这篇关于我需要在共享内存对象上使用shm_unlink吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！