From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13401 invoked by alias); 20 Dec 2013 22:51:57 -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 13352 invoked by uid 48); 20 Dec 2013 22:51:54 -0000 From: "bugdal at aerifal dot cx" To: glibc-bugs@sourceware.org Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Fri, 20 Dec 2013 22:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.15 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bugdal at aerifal dot cx X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: carlos at redhat dot com X-Bugzilla-Target-Milestone: 2.18 X-Bugzilla-Flags: review? X-Bugzilla-Changed-Fields: 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: 2013-12/txt/msg00186.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #30 from Rich Felker --- Carlos, there's nothing "conservative" about giving applications broken semantics on the basis that you're not sure the standard _requires_ the correct semantics. And there's no reason to wait for a response from the Austin Group to fix this. Even if, by some fluke, they removed the requirement that ending the "reference" to a mutex is atomic with unlocking it, you would still want to have the correct, safe semantics just for the sake of applications using it. THIS is the conservative behavior. Torvald, in regards that there are "other ways" to do end-of-lifetime detection, the only way to do so in a strictly conforming application, if you don't have the self-synchronized destruction property for at least one of mutexes, semaphores, or spinlocks, is with a _global_ lock ensuring that no two threads can be attempting to release a reference to the same type of reference-counted object at the same time. This is obviously not practical from a performance standpoint, and it's also hideous from a "global state considered harmful" standpoint. Obviously with other tools that will be available in future editions of POSIX (e.g. C11 atomics) and that are available now as extensions, you can work around the problem by refraining from using mutexes, but that's not a good solution. -- You are receiving this mail because: You are on the CC list for the bug.