From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2476 invoked by alias); 6 Jan 2014 21:20:08 -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 2118 invoked by uid 48); 6 Jan 2014 21:20:04 -0000 From: "triegel at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access Date: Mon, 06 Jan 2014 21:20: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: triegel 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: 2014-01/txt/msg00077.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #35 from Torvald Riegel --- (In reply to Rich Felker from comment #34) > > > or (b) wait for all threads to exit. > > > > Precisely, wait for all threads that use the particular resource to not use it > anymore. That's different from "wait[ing] for all threads to exit". > > That requires a mutex. So you just moved the mutex issue to a different > mutex; you didn't solve it. Consider a thread pool, or something else that manages a set of threads. The lifetime of this thing will be larger than the lifetime of the threads themselves. You will want to do pthread_join on the threads eventually, if you're interested in safe destruction. Once you do that, you can safely destruct the thread pool at that time, including any mutexes in it. If you want to keep the threads around for longer (e.g., so that they can work on more than one task), you can easily let them signal the thread pool once they've finished the task. For that, you can use a mutex in the thread pool for example. Thus, there is a straightforward way to do it without reference counting. Having a mutex or similar on the thread pool is not something that's bad. You will have the thread pool (or a pthread_t at the very least anyway). If we didn't have pthread_join, or one would have to implement its functionality with a pthread_mutex_t, then we would have a problem. But that's not the case, we do have pthread_join() to eventually break the chain you seem to be concerned about. > > > You are arguing for (b): To destroy a mutex -- any mutex -- you must first > > > wait for every thread that ever touched that mutex to exit. > > > > This could be a reasonable semantics. > > No, you stopped being reasonable several posts back in this thread. I'm not > sure what your emotional attachment to glibc's current brokenness with > respect to this issue is, but it's completely clouding your judgement and > making you look like a fool. It's really sad to see this kind of response to > bugs again when glibc was just recovering from the madness of the former > maintainer and his attitude towards bug reports... I have no emotional attachment to anything here. That includes the stronger semantics you want to have, your assumptions about my judgement, etc. You haven't made a convincing argument why the semantics as targeted by the current glibc implementation would be incorrect (if the issue above is what worries you, let's keep discussing that one). I understood that you'd want something stronger, and I appreciate that you have an opinion on this, but ultimately I think glibc should implement what POSIX wants, thus the clarification request. Also, if you (and Pat) want the glibc community to be a place where technical issues are solved in a constructive manner, then you should probably remind yourselves that you and your actions are very much a part of this. -- You are receiving this mail because: You are on the CC list for the bug.