從我有限的Boost.Interprocess經驗中,我沒有任何重大問題,但我無法真正評論性能。雖然確實使用在程序文件夾外部創建的文件來完成它們的工作,但它們都應該是內存映射的,這可以消除大多數性能問題。無論如何,當你使用IPC時,你應該總是期望額外的性能開銷。
至於您突出強調的批評,可以刪除一個已命名的互斥體或任何其他命名資源,這些資源已被前一個進程留下(請參閱靜態的remove(const char*)
函數)。公平地說,取決於您的應用程序,正確使用這可能會非常棘手,這在使用Windows API時不是您必須處理的。另一方面,Windows API不可移植。我的猜測是,他們使用文件(即使有更好的替代方案),以保持庫的界面和行爲在不同平臺之間保持一致。
無論如何,命名互斥體只是圖書館提供的一小部分。其中一個更有用的功能是它提供了own memory managers for the shared memory region其中包括STL allocators。我個人覺得使用它提供的高級構造與原始內存一起工作會更愉快。
更新:我沒多一些挖Boost文檔中,我在各種有趣的TID位傳來:
This page提供有關執行情況的一些詳細信息和庫的性能,但不包含實施原理。
This link明確指出他們的Windows互斥體實現可以使用一些工作(版本1.46)。如果您在boost\interprocess\sync
文件夾中進一步挖掘,您會注意到另外兩個名爲posix
和emulation
的文件夾。這兩個都包含同步原語的實現細節。爲interprocess_mutex::lock
POSIX的實現是你期望什麼,但仿真的實現是非常基本的:
// Taken from Boost 1.40.
inline void interprocess_mutex::lock(void)
{
do{
boost::uint32_t prev_s = detail::atomic_cas32(const_cast<boost::uint32_t*>(&m_s), 1, 0);
if (m_s == 1 && prev_s == 0){
break;
}
// relinquish current timeslice
detail::thread_yield();
}while (true);
}
所以由它的外觀,它們的目的是對POSIX的支持和blobbed一切成使用內存映射的仿真層文件。如果你想知道他們爲什麼不提供專門的Windows實現,那麼我建議你詢問Boost郵件列表(我在文檔中找不到任何東西)。
缺少您需要的功能?如果答案是沒有,我不明白爲什麼你需要擔心其他人可能不會分享你的需求的「批評」... – Nim
他們究竟批評什麼?你能提供鏈接嗎?就像這樣,問題太模糊 –
這不是特徵,而是被批評的實現。我不明白這個問題是如何模糊的......如果Boost的實現存在問題,那麼分享它們,如果有更好的庫,請列出它們。 –