2

I need a "lock" that can be either shared or held exclusively, that will provide the following behavior for the following sequence of events:

  1. Process A: Requests and is granted a shared lock
  2. Process B: Requests an exclusive lock, and is blocked by A's ownership of the lock
  3. Process C: Requests a shared lock, and is blocked because B is in line for an exclusive lock

I had thought that the Unix flock would provide these semantics, but then discovered that in step 3, Process C's request for a shared lock would succeed, and Process B's request for an exclusive lock would only be granted when there were no shared locks being held. This has the unfortunate (for me) effect that, the more concurrent processes there are requesting shared locks, the longer a process requesting an exclusive lock will have to wait for a window in which there are no outstanding shared locks being held.

The behavior I seek, in other words, is that, from the time that a process requests an exclusive lock, through the time that it is granted the lock and until the time that it releases the lock, all subsequent shared lock requests will be queued and blocked.

What type of lock has the properties that I need?

Chap
  • 723
  • 1
  • 7
  • 18
  • 1
    I edited your question to ask for the answer itself rather than a name to search on. This site is about providing answers, not Google-fu tips. –  Dec 19 '14 at 17:55

2 Answers2

2

You need a read-write lock that will prioritize its write locks. A you can set a posix' rwlock to prefer the writer during its initialization.

Or as said in the linked wiki page:

Write-preferring RW locks avoid the problem of writer starvation by preventing any new readers from acquiring the lock if there is a writer queued and waiting for the lock. The writer will then acquire the lock as soon as all readers which were already holding the lock have completed. The downside is that write-preferring locks allows for less concurrency in the presence of writer threads, compared to read-preferring RW locks. Also the lock is less performant because each operation, taking or releasing the lock for either read or write, is more complex, internally requiring taking and releasing two mutexes instead of one. This variation is sometimes also known as "write-biased" readers-writer lock.

ratchet freak
  • 25,706
  • 2
  • 62
  • 97
  • 1
    I can understand, from the description that you've included, how this type of lock provides the behavior I'm seeking. You've provided me with a name for the concept, which was what I expected from a forum for conceptual questions about software development. You mentioned `rwlock`, though, which (as I understand it) pertains to POSIX *thread* locking. Are there POSIX services that provide Write-preferring RW locks for interprocess coordination? Or should I pursue the question of implementation in a different forum? – Chap Dec 19 '14 at 23:12
0

All you really need to build arbitrary locking structures is a mutex and a state variable. In the context of the filesystem, a mutex consists of open("/tmp/foo.lock", O_WRONLY|O_TRUNC|O_CREAT|O_EXCL) to acquire (followed by a call to close()) and remove("/tmp/foo.lock") to release. To block on the mutex, use inotify or (if you know it will not remain locked or suffer heavy lock contention) busy-wait on it. The state variable can be a secondary file in /tmp (or elsewhere, if you can live with cleaning up stale files by hand after your program crashes). The rest should be fairly straightforward to design.

Kevin
  • 2,668
  • 2
  • 15
  • 23