Aug 5, 2020

The original simple startup/shutdown use of the lock is straightforward. However write flushing is essentially transactional commit. In v3 this could be guarded in each data file write independently. However v4 incorporates multi-file transactions, materially complicating write flushing. As you can see the lock attempts are not guarded, so the class is not thread safe across the shared lock file resource. In order to properly support transactional commit the class needs to accept a flush mutex and use it to apply an upgradeable lock around the lock file access. This will allow the flush lock to become an actual guard for transactional commit.