From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2213 invoked by alias); 11 Jan 2014 06:08:50 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 2165 invoked by uid 48); 11 Jan 2014 06:08:45 -0000 From: "wolfgang at contre dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/16285] thread-safe file locking (using lock file) Date: Sat, 11 Jan 2014 06:08:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: wolfgang at contre dot com X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg00183.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16285 Wolfgang Sourdeau changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #8 from Wolfgang Sourdeau --- (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.