From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18752 invoked by alias); 6 Jan 2014 16:58:51 -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 18668 invoked by uid 48); 6 Jan 2014 16:58:48 -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 16:58: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/msg00071.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #31 from Torvald Riegel --- (In reply to Rich Felker from comment #30) > 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. You can't claim that just one of the semantics is "correct". They, obviously, can both be used in meaningful ways. We can certainly argue about the utility of both of the semantics, but that's different from correctness. Also, because you mentioned conforming applications: those won't be helped by glibc implementing something (incl. something stronger) that's not guaranteed by POSIX. > 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. No, it does not need to be a global lock. You just make sure that all threads that use the resource you want to destruct have quiesced. For example, if you've spawned a set of threads to do work concurrently on a resource, and join them after they've done the job, then pthread_join does exactly this for you; afterwards, whichever thread spawned those threads can initiate destruction. If you've used a task queue or similar on a thread pool, the task queue can do the same. > This is obviously not practical > from a performance standpoint, I don't see how the thread pool, for example, is bad in terms of performance. > and it's also hideous from a "global state > considered harmful" standpoint. This is not about global vs. non-global state, but instead about how to ensure quiescence of concurrent threads: you initiate concurrent execution, and once that's done and there's no concurrency anymore, you destruct. The main thread might be the thread that's doing that, and it might use global state for that, but that's not necessarily so. -- You are receiving this mail because: You are on the CC list for the bug.