3

I have been having issues using an anonymous mutex (boost::interprocess::interprocess_mutex) in a boost::interprocess::managed_shared_memory instance. Namely, issues arise if the software crashes; the mutex may remain locked (depending on its state at time of crash). It can make debugging interesting too :).

My understanding is that I can substitute the interprocess_mutex with boost::interprocess::file_lock (FL). @DaveF posted some questions that I would like to build upon. I'd like to have a good understanding what I'm getting myself into before I put FL into use.

  • Can I use an anonymous boost::interprocess::condition_variable (CV) with FL? Having looked through the code, it appears that it will work.
  • In using a CV, am I opening myself up to the same problems I have experienced when using mutex (ie. if the application unexpectedly ends without proper cleanup/finalisation)?
  • What is the best way to create a FL. I've thought about something similar to the following...

Note code may not compile:

namespace bi = boost::interprocess;
namespace bf = boost::filesystem;

const std::string strSharedMemName = std::string("cp_shdmem_") + std::to_string(nIdx);
const std::string strNamedMutexName = strSharedMemName + "_mtx";

// I'm working on Linux, but would like to Boost to create a temporary file path.
const bf::path pathTmpFile =
    bf::temp_directory_path() / (strNamedMutexName + ".txt");

{
    // 1. So can I just create the file? What happens if it exists? Boost docs say this
    // about the file_lock constructor:
    //   "Throws interprocess_exception if the file does not exist 
    //    or there are no operating system resources."
    // 2. What happens if file already exists?
    bf::ofstream f(pathTmpFile);
}

// Create.
bi::file_lock lockFile(pathTmpFile.string().c_str());

// Lock.
bi::scoped_lock<bi::file_lock> lockNamed(lockFile);

Platform specifics:

  • Ubuntu 17.10
  • Boost 1.63
  • GCC 7.2
ZeroDefect
  • 663
  • 1
  • 8
  • 27

0 Answers0