It might be worth investigating some other projects that use lock
files. Git, as mentioned locks the index with a lock file, but AFAIK
without counting. As a reference for the NFS issue, see
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html
section 7.11.2.1, which says:
Second, if the lock file may be on an NFS-mounted filesystem, then
you have the problem that NFS version 2 doesn’t completely support
normal file semantics. This can even be a problem for work that’s
supposed to be “local” to a client, since some clients don’t
have local disks and may have all files remotely mounted via NFS. The
manual for open(2) explains how to handle things in this case (which
also handles the case of root programs):
“... programs which rely on [the O_CREAT and O_EXCL flags of
open(2) to work on filesystems accessed via NFS version 2] for
performing locking tasks will contain a race condition. The solution
for performing atomic file locking using a lockfile is to create a
unique file on the same filesystem (e.g., incorporating hostname and
pid), use link(2) to make a link to the lockfile and use stat(2) on
the unique file to check if its link count has increased to 2. Do not
use the return value of the link(2) call.”
The question is if this applies to current NFS versions (3, 4).
However, If I read this correctly, the link count strategy can be used
to encode more info. However, this again depends on OS-specific
extended attributes, which is contrary to the general file-system based
locking I was looking to create.
As an aside, I don't quite understand why and how a reader/writer lock
requires/uses a counter. I'd appreciate a link to any documentation
about that.
---
Pierre Tempel
On Sa, Dez 15, 2018 at 9:43 , Richard Hipp <d...@sqlite.org> wrote:
On 12/15/18, Pierre Tempel <pierretem...@gmail.com> wrote:
Hm. Doesn't this mean the proposed solution still works, but with
directories instead of files for the sake of atomicity? I.e. for
each
lock type, create a unique dir name (e.g. ".1.lock") and stat for
all
lock types when changing levels?
I think you probably need a counter in order to implement a
reader/writer lock, don't you?
We used to do a stocastic simulation reader/writer locks on win98 by
using 512 separate locking bytes. But is seems a little excessive to
have 512 separate locking directories.
Does anybody else know how to implement reader/writer locks using
lock files?
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
