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] thread-safe file locking (using lock file)


https://sourceware.org/bugzilla/show_bug.cgi?id=16285

Wolfgang Sourdeau <wolfgang at contre dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #8 from Wolfgang Sourdeau <wolfgang at contre dot com> ---
(In reply to Ondrej Bilka from comment #7)
> I agree with Rich here, link with checking EEXIST suffices.

No it does not. As mentionned above. EEXIST does not enable the safe removal of
stale lock files. The problem is the handling of stale lock files in a
multi-threaded program:
- either they exist indefinitely and the threads are locked until a manual
intervention is performed
- either they are replaced automatically with the risk of a race condition,
because using "link" requires "unlink" and 2 threads can execute "unlink"
simultaneously without knowing that they are removing a new valid lock file
from another active thread.

I can provide code that illustrate that if you wish but do a search on "linux
lock threads" and you will notice that I am not the only one having that issue.

An alternative method, which I have found meanwhile, is to use robust mutexes
with a mmapped file. That solution works perfectly well. I still think that my
solution would be elegant though, as it would also enable the automatic cleanup
of files following a program crash.

-- 
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]