0

I am working on a project that uses boost::interprocess_mutexes all over the place, even though the application never even fork()s children, but heavily relies on multi-threading.

Is it correct to assume that all those interprocess_mutexes could be replaced by process local mutexes without breaking anything?

Is my assumption that this could potentially boost performance (if only by a minimal factor) correct?

Is there any conceivable reason for using interprocess synchronisation within a single (optionally multi-threaded) process?

idefixs
  • 712
  • 1
  • 4
  • 14
  • Does it use shared memory? and is that memory used by multiple applications? Thats the test - it doesn't have to fork, there could be different code bases (separate executables) sharing some resource. (But if not then I would ***guess*** that you could use normal mutexes) – Caribou Dec 04 '12 at 13:24

1 Answers1

3

Does it use shared memory or some other IPC mechanism? and is that memory used by multiple applications? Thats the test...

It doesn't have to fork, there could be different code bases (separate executables) sharing some resource. For example is there a monitoring application or interface that gets stats from the app as it runs via some IPC mechanism? Note that there may be other better ways of doing that, it's just an example.

Looking at the headers :

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

There is an overhead and replacing it with a local version (If Safe) could gain you some efficiency. I'm not too familiar with the Posix implementation in all honesty however.

As I said above you might use IPC if an external app were using some say shared memory to get stats or communicate - but if that's not the case for you then you can probably replace them.

Caribou
  • 2,070
  • 13
  • 29