This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16285] New: thread-safe file locking (using lock file)
- From: "wolfgang at contre dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Mon, 02 Dec 2013 21:53:17 +0000
- Subject: [Bug libc/16285] New: thread-safe file locking (using lock file)
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=16285
Bug ID: 16285
Summary: thread-safe file locking (using lock file)
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: wolfgang at contre dot com
CC: drepper.fsp at gmail dot com
As you know, lockf, flock and fcntl are not useful to guarantee the ownership
of a lock for an unexisting file. To my knowledge, the only way to guarantee
that a yet-to-be-created file is properly locked beforehand is by using the
O_CREAT flag with "open". Then, a dead lock problem occurs if this is performed
on the original file, as there would be a priori no way to know if an existing
file is actually being created or if its creator process died, thereby leading
to a dead lock. One possibility is thus to use a separate specific lockfile
containing the pid ot the tid of the calling thread, which could then be
checked for "staleness" by other threads by writing the active pid/tid to it
and checking it back. Now, the problem with this approach is that if the file
is checked by two simultaneous processes and that they both attempt to acquire
it, there is no way to ensure that one of them would not unlink the version
just created by the other process. This, in turn, causes a race condition over
the lock file, which takes us back to our original problem.
What I think is that a correct way to avoid deadlocking would be if the kernel
could somehow guarantee that a file could be unlinked from the filesystem as
soon as it is closed or if it's creator process terminates (which would also
imply the former). I would thus propose a "O_UNLINK" flag to "open" which would
allow that.
--
You are receiving this mail because:
You are on the CC list for the bug.