I need a “lock” that can be either shared or held exclusively, that will provide the following behavior for the following sequence of events:
- Process A: Requests and is granted a shared lock
- Process B: Requests an exclusive lock, and is blocked by A’s ownership of the lock
- 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?
1
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.
1
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.