Is Boost IPC any good? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

My default choice for cross-platform IPC would be boost, but I saw it criticised in two different forums when I asked about it and this concerned me. Perhaps this was simply a coincidence, so w开发者_运维知识库hat are the thoughts on boost IPC and choosing a cross-platform C++ IPC library in general?

For Windows dev we're using VC++ 2008 for reference.

edit: here is an example of comments I've seen made (can't find them all right now):

for boost, it's crap. At least on windows. The Mutexes don't use WinAPI, instead they create it's own File-Based implementation (WinAPI = Kernel-Objects). If your Program crashes the files won't be deleted. Next time your Programm is launched the mutex can't be created, because of the existing file.

---

From my limited experience with Boost.Interprocess, I didn't have any major problems but I can't really comment on performance. While it's true that it does use files created outside of your program's folder to do its stuff, they should all be memory mapped which negates most of the performance problems. In any case, when you're using IPC you should always expect some extra performance overhead.

As for the criticism you highlighted, it is possible to remove a named mutex or any other named resources that has been left lying around by a previous process (see the static remove(const char*) function). To be fair, depending on your application, it might be tricky to use correctly which is not something you have to deal with when using the Windows API. On the other hand, the Windows API isn't portable. My guess is that they use files (even when better alternative exists) to keep the interface and behaviour of the library consistent across different platforms.

Anyway, named mutexes is only small part of what the library provides. One of the more useful features is that it provides its own memory managers for the shared memory region which includes STL allocators. I personally find it more pleasant to work with the high level constructs it provides then with raw memory.

---

UPDATE: I did some more digging the in the Boost documentation and I came across various interesting tid bits:

This page gives a bit more detail about the implementation and the performances of the library but doesn't include an implementation rationale.

This link clearly states that their Windows mutex implementation could use some work (version 1.46). If you dig a little further in the boost\interprocess\sync folder, you'll notice two more folders named posix and emulation. Both of these contains the implementation details for the synchronisation primitive. The posix implementation for interprocess_mutex::lock is what you'd expect but the emulation implementation is pretty basic:

// 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);
}

So by the looks of it, they aimed for Posix support and blobbed everything else into an emulation layer which uses memory mapped files. If you want to know why they don't provide a specialised Windows implementation then I suggest asking the Boost mailing list (I couldn't find anything in the doc).

---

This is not a direct answer to your question, but an alternative: If you have a choice on the dev environment then you can consider Qt and the D-bus implementation in Qt.