There is currently no specification for multiple agents attempting to fsyncLock() a mongod instance. However, the observed behavior is somewhat confusing. Observed behavior, from a single mongo shell:
At first blush, this appears like the fsyncLock is a shared, recursive resource, and every acquisition must be paired with a release. However, this is misleading. What in fact happens is that the second acquisition returns, reporting success, if the first acquirer has the lock, and in the background on mongod, the lock request gets queued up. When the first acquisition is released with fsyncUnlock(), the pending lock request gets processed, and the fsync lock is re-acquired. There is a brief period where the fsync lock is unheld.
- Fix the race condition, maintaining a locked read-only file set until all clients have unlocked.
- Make lock state clearer to clients, so that the message provides the information needed to understand current state.