如何测试 boost 共享内存对象是否被删除？
我在进程之间使用 boost::interprocess::shared_memory_object 。
进程（服务器）创建共享内存对象，其他进程（客户端）打开该共享内存对象。但是，客户端进程如何确定该共享内存对象是否被服务器进程删除？
由于引用缓存，我需要这种删除检测。我的意思是，客户端进程存储对共享内存的引用，并在需要时重用它。但是，当服务器进程删除共享内存并使用相同名称重新创建共享内存时，我只想让我的客户端进程检测到这一重新创建并更新对新创建的共享内存对象的引用。
I'm using boost::interprocess::shared_memory_object between the processes.
A process (server) creates a shared memory object, and other processes (clients) open that shared memory object. But, how can client processes determine if that shared memory object is removed by server process?
As boost documentation states, when the shared memory is requested to be removed, it won't be deleted until all other references de-refer it. So, even if the server process (tries to) delete the shared memory object, that shared memory object is not deleted, and, so other client processes cannot know that was deleted or not.
I need this kind of delete-detection because of the reference caching. I mean, client processes stores the reference to the shared memory, and reuse it whenever needed. But, when the server process delete the shared memory and recreate one using the same name, I just want my client processes to detect this recreation and update the reference to the newly created shared memory object.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
该命令
将显示所有现有的共享内存段。到shmid时，您应该能够识别您的细分。还有 nattch 列，显示该段的附加进程数。
The command
will display all existing shared memory segments. By shmid you should be able to identify your segment. There's also nattch column showing number of attached processes to the segment.
您可以在共享内存对象中包含一个标志，指示您的服务器进程是否仍在使用它。
在服务器进程尝试删除共享内存之前，将此标志设置为 false。当客户端进程发现该标志为 false 时，它们可以关闭对该对象的引用。
另外，我不认为服务器进程将被允许重新创建具有相同名称的共享对象，直到它被删除，因为我确信名称必须是唯一的。
You could include a flag in your shared memory object that indicates if your server process is still using it.
Set this flag to false before your server process attempts to delete the shared memory. When the client processes see that the flag is false they can close their references to the object.
Also, I don't think the server process will be permitted to recreate a shared object with the same name until it has been deleted, as I am sure the names must be unique.