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

["wolfgang at contre dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #2 from Wolfgang Sourdeau <wolfgang at contre dot com> ---
(In reply to Rich Felker from comment #1)
> Could you clarify the intended usage case? I'm not clear on why this
> functionality is essential, and perhaps knowing what you need it for would
> help in recommending an alternate solution.

Yes of course!

The use case is as follows... A multithreaded process that download files from
a remote connection and caches them on the local fs. A similar process may
already be running on the same machine or even a similar thread. Before the
download, we need to check whether a copy of the file already exists. If it
does, we open it, otherwise we create it and download its actual content.
Moreoever, there is to know that the cache location is intentionnally the same
for all threads and processes.

Initially, the problem was that a race condition would sometimes occur and the
same file would be downloaded simultaneously from 2 threads/processes or more,
overwriting one another's output. The fix I decided to use was a lock file
created with O_CREAT and O_EXCL, and where the active thread id (gettid) would
be put to enable other threads to identify the owner. Since this code is
actually part of a library, it may occur that the process will crash due to a
bug in another thread. Therefore I need to handle stale lock files by checking
for the tid's validity. If the tid is invalid, the lock file is unlinked and
recreated by the new thread.

Now, the situation that occurs here is another race condition, where between
the unlinking and the creation of the new file, another thread or process may
have actually read the old version and unlinked the new version, "thinking" it
was the old one. And that is the race condition I am trying to think about, in
the cleanest possible way. Arguable, I could retest whether I still own the
lock file after creating it and after a small delay, but I would not consider
this as a valid solution. Also, I have done some research on a few blogs and
q&a sites and never found a satisfactory answer to that problem.

> 
> In any case, new open flags are a kernel matter; glibc has nothing to do
> with getting such a feature added, but would need to add the macro to its
> headers if it were added.
> 
> BTW, the bits of the open flags int are almost exhausted, so asking for new
> features there is really not appropriate unless they're extremely important.

I understand but I figured that from my point of view it would be better to
start what the libc developers would think about this first before going
further. Simply because from a user program, the libs provides the relevant
interfaces.

-- 
You are receiving this mail because:
You are on the CC list for the bug.