在 NFS 上查询 boost interprocess::file_lock

Question

We have an application which user can run to generate some data at user specified path. This unique output data is generated with respect to one unique input data-set - this input data is provided by the user.

When we initially developed the application, we never anticipated that number of unique input data-set will be large (due to nature of application). Our expectation was number of unique input data-set could be of order of 10 where as one user has this as 1000. So, that particular user started 1000 jobs of our application on grid and all writing data to same path. Note - these 1000 jobs are not fired from our application and rather he spawned 1000 processes of our application on different machines.

Now this lead to some collision and data loss.

To guard against it, I am planning to synchronization using boost::interprocess. This is what I am planning:

// usual processing of input data ...

boost::filesystem::path reportLockFilePath(boost::filesystem::system_complete(userDir));
rerportLockFilePath.append("report.lock");

// if lock file does not exist, create one
if (!boost::filesystem::exists(reportLockFilePath) {
    boost::interprocess::named_mutex reportLockMutex(boost::interprocess::open_or_create, "report_mutex");
    boost::interprocess::scoped_lock< boost::interprocess::named_mutex > lock(reportLockMutex);

    std::ofstream lockStrm(reportLockFilePath.string().c_str());
    lockStrm << "## report lock file ##" << std::endl;
    lockStrm.flush();
}

 boost::interprocess::file_lock reportFileLock(reportLockFilePath.string().c_str());
 boost::interprocess::scoped_lock< boost::interprocess::file_lock > lock(reportFileLock);

 // usual reporting code that we already have ...

Now, questions are -

• If this is correct synchronization for the problem at hand
• If this synchronization scheme will work, when jobs are on different machines and path is on NFS
• If on NFS etc., this is not going to work, what are the C++ alternatives? I prefer to avoid lower level C functions to avoid race condition due to lock being held when one instance of execution crashes etc.

Answer 1

I just removed the named mutex part (as that was causing problem on few machines due to permission issue - probably related to umask issue discussed in this context in some other post) and replaced with

std::ofstream lockStrm(reportLockFilePath.string().c_str(), std::ios_base::app);
    

And it worked at least in our internal testing.