2

I have files residing in different directories as follows:

\201603\30
           file_1
           file_2
\201603\31
           file_3
           file_4
           file_5

There are 2 writers & 2 readers and they are all threads in my program.

Lock will be applied on directory not individual files (e.g. \201603\30 or \201603\31).

I would like to use boost library to make my program portable.

I have searched and been introduced to boost::interprocess::file_lock. I was just wondering that do I really need an 'interprocess' lock here, and is that lock sharable between readers? Do you have any suggestions other than boost::interprocess::file_lock?

duong_dajgja
  • 4,196
  • 1
  • 38
  • 65

2 Answers2

1

Since all lock users in are in your program, what do you need interprocess locking for? file_lock puts the mutex into a file which lets the kernel manage locking/unlocking. This is only useful if multiple processes need to respect the lock.

It sounds like you need nothing more than a regular read-write lock, which Boost calls shared_lock. See this answer for an example on how to use one: https://stackoverflow.com/a/989816/321772

In summary, a shared lock lets multiple threads acquire the lock for reading, but only allows one thread to upgrade the lock to a writer (excludes all other readers/writers).

Community
  • 1
  • 1
Adam
  • 16,808
  • 7
  • 52
  • 98
  • I already know about and have been using `shared_mutex` in my program but for other purpose. For this question, however, I would like to lock on directory. That means, say, writer is writing to `\201603\30\file_1` readers still can read data in `\201603\31\*`. How can I match directory with the `shared_mutex`? – duong_dajgja Mar 30 '16 at 06:15
  • @duong_dajgia I think you need 2 rw-locks, one on 2016\03\30 and the other on 2016\03\31. Before any of your threads accessing a directory, it should fetch the related rw-lock. For example, T1 wants to access 2016\03\30\1.txt, it should try to get the rw-lock on directory 2016\03\30. Actually, lock on dir or file does not make a difference. – DAG Mar 30 '16 at 06:40
  • @DAG sounds like not a good solution. The directories are created in run-time. – duong_dajgja Mar 30 '16 at 06:46
  • 1
    Then have one lock per directory. Heck, phrasing like "lock on directory" implies you're not thinking of anything more complex than a basic mutex. If your question is how to keep track of those locks, may I suggest `unordered_map` – Adam Mar 30 '16 at 06:47
  • @duong_dajgia Check out Adam's solution. – DAG Mar 30 '16 at 06:55
  • BTW, I prefer to use std::shared_mutex rather than the boost version. – DAG Mar 30 '16 at 06:57
0

As the other responder mentioned, because only one process is using the files you don't need to lock on the filing system, a std::shared_mutex or even a plain old std::mutex should be plenty.

If however you were needing to lock efficiently across multiple processes, and it is now 2017 or later, you might consider using one of the shared_fs_mutex algorithms in the post-peer-review rewrite of proposed Boost.AFIO v2: https://ned14.github.io/boost.afio/namespaceboost_1_1afio_1_1v2_1_1algorithm_1_1shared__fs__mutex.html. The reason I caveat the year being 2017 is that AFIO v2 doesn't even have a test suite yet, it is highly alpha code and I cannot recommend anyone use it yet.

Niall Douglas
  • 9,212
  • 2
  • 44
  • 54
  • The Boost.AFIO link seem to be broken, newer link would be: https://ned14.github.io/llfio/classllfio__v2__xxx_1_1unique__file__lock.html#ac66e90389ea1568453ca7df71db96f16 – vmiheer Mar 19 '21 at 02:01