повысить понимание / использование межпроцессных файловых блокировок

У меня возникли проблемы с использованием анонимного мьютекса (boost::interprocess::interprocess_mutex) в экземпляре boost::interprocess::managed_shared_memory. А именно, проблемы возникают при сбое программного обеспечения; мьютекс может оставаться заблокированным (в зависимости от его состояния во время сбоя). Это тоже может сделать отладку интересной :).

Насколько я понимаю, я могу заменить interprocess_mutex на boost::interprocess::file_lock (FL). @DaveF опубликовал несколько вопросов На этом хотелось бы развить. Я хотел бы иметь хорошее представление о том, во что я ввязываюсь, прежде чем начну использовать FL.

  • Могу ли я использовать анонимное boost::interprocess::condition_variable (CV) с FL? Посмотрев код, оказалось, что он будет работать.
  • При использовании резюме открываюсь ли я тем же проблемам, с которыми я столкнулся при использовании мьютекса (например, если приложение неожиданно завершается без надлежащей очистки / завершения)?
  • Как лучше всего создать ФЛ. Я думал о чем-то похожем на следующее ...

Примечание код может не компилироваться:

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

Особенности платформы:

  • Ubuntu 17.10
  • Повышение 1.63
  • GCC 7.2

person ZeroDefect    schedule 02.04.2018    source источник