From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22169 invoked by alias); 20 Dec 2013 19:38:27 -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 22060 invoked by uid 48); 20 Dec 2013 19:38:24 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Fri, 20 Dec 2013 19:38: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: carlos at redhat dot com 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/msg00177.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #28 from Carlos O'Donell --- (In reply to Pat from comment #27) > If you have to wait for all calls to mutex_unlock to return before you can > destroy the mutex, how are you supposed to guarantee that, exactly? > > You can only do so by synchronizing the threads in some other way. So every > mutex has to be guarded by another mutex which has to be guarded by another > mutex... > > ...except for the last mutex, which is global or static or whatever and > never gets destroyed. Problem solved! > > Seriously, think about the kind of code you would have to write to deal with > these semantics. Is that what you think POSIX wanted to put people through > (despite the actual example they give)? Is that what glibc wants to put > people through? > > You do not need "clarification" from anybody to recognize that these are > serious bugs. The only interesting question is how many years it's going to > take. That may be the case for normal software projects, but this is glibc. We are a conservative project and we work through a standards process and collaborate with the Austin Group and the ISO group on POSIX and ISO C. I understand that this is sometimes frustratingly slow, but it ensures a clarity and quality that we desire to achieve with the project. I don't disagree that it seems ridiculous to require such complexity, but we want to gather consensus from the Austin Group to ensure that we understand all the implications before we make a change. -- You are receiving this mail because: You are on the CC list for the bug.