This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/16285] New: thread-safe file locking (using lock file)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]