我正在开发一个到处使用boost::interprocess_mutex
es 的项目,尽管该应用程序甚至从来没有fork()
孩子,但严重依赖于多线程。
假设所有这些interprocess_mutex
es 可以被进程本地互斥体替换而不破坏任何东西是否正确?
我认为这可能会提高性能(如果只是一个最小的因素)的假设是否正确?
在单个(可选多线程)进程中使用进程间同步是否有任何可以想象的理由?
我正在开发一个到处使用boost::interprocess_mutex
es 的项目,尽管该应用程序甚至从来没有fork()
孩子,但严重依赖于多线程。
假设所有这些interprocess_mutex
es 可以被进程本地互斥体替换而不破坏任何东西是否正确?
我认为这可能会提高性能(如果只是一个最小的因素)的假设是否正确?
在单个(可选多线程)进程中使用进程间同步是否有任何可以想象的理由?
它是否使用共享内存或其他一些 IPC 机制?该内存是否被多个应用程序使用?那就是测试...
它不必分叉,可能有不同的代码库(单独的可执行文件)共享一些资源。例如,是否有一个监控应用程序或接口在通过某种 IPC 机制运行时从应用程序获取统计信息?请注意,可能还有其他更好的方法可以做到这一点,这只是一个示例。
看标题:
http://www.boost.org/doc/libs/1_52_0/boost/interprocess/sync/windows/mutex.hpp
http://www.boost.org/doc/libs/1_52_0/boost/interprocess/sync/posix/mutex.hpp
有开销,用本地版本(如果安全)替换它可以提高效率。但是,老实说,我对 Posix 的实现不太熟悉。
正如我上面所说,如果外部应用程序使用共享内存来获取统计信息或通信,您可能会使用 IPC - 但如果您不是这种情况,那么您可能可以替换它们。