我正在为一个共享内存应用程序使用boost interprocess,我觉得它处理进程终止的能力非常差。
例如,我创建一个特定的数据对象并将其存储在内存中,名称为map_name。然后,我运行以下代码:
void findContinuously(const char* map_name) {
managed_shared_memory segment(open_only,"MySharedMemory");
while(true) {
DataObject *myMap = segment.find<DataObject>(map_name).first;
bsl::cout << myMap << bsl::endl;
}
}
创建对象后我第一次运行它,一切正常。它不断地打印一个地址。然后我按ctrl-c。再次运行它。按ctrl-c。我一遍又一遍地重复这个过程。最终,也许它运行3,程序挂起,从不打印任何地址,但从不退出。我按ctrl-c再次尝试,但无济于事。从这里开始,对象是不可访问的。而且,我无法再在此managed_shared_memory段中创建新对象。
我有一个理论来解释为什么会发生这种情况。managed_shared_memory对象保证了对象的创建和搜索是原子的。它可能通过在共享内存中有一些互斥来实现这一点。调用进程访问段管理器,段管理器获得这个互斥。在段管理器释放互斥之前,进程死亡。互斥被永远锁定。
我有这个想法是因为当我在另一种情况下使用我自己的命名共享内存互斥锁时,这种情况就发生了。
有什么想法吗?我没有解决办法。这让我无法在生产环境中使用boost进程间,因为进程偶尔会被杀死。我不能冒险锁定整个内存块。但我很难相信Boost开发人员没有预见到这种情况。
1条答案
按热度按时间rekjcdws1#
尝试使用typedef获取默认的basic_managed_shared_memory,并使用空互斥体系列的窄字符:typedef basic_managed_shared_memory〈char,rbtree_best_fit<null_mutex_family>,iset_index〉managed_shared_memory_null_mutex;并在managed_shared_memory_null_mutex外部使用健壮的进程间锁,如system V信号量。