public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "triegel at redhat dot com" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-13690-131-rjXvNjQE34@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-13690-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=13690 --- Comment #31 from Torvald Riegel <triegel at redhat dot com> --- (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.
next prev parent reply other threads:[~2014-01-06 16:58 UTC|newest] Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-02-14 14:28 [Bug nptl/13690] New: " anemo at mba dot ocn.ne.jp 2012-02-14 14:29 ` [Bug nptl/13690] " anemo at mba dot ocn.ne.jp 2012-02-14 15:39 ` carlos at systemhalted dot org 2012-02-14 15:41 ` carlos at systemhalted dot org 2012-02-14 15:42 ` carlos at systemhalted dot org 2012-02-15 6:47 ` ppluzhnikov at google dot com 2012-02-15 13:18 ` anemo at mba dot ocn.ne.jp 2012-02-15 14:35 ` carlos at systemhalted dot org 2012-02-16 5:09 ` bugdal at aerifal dot cx 2012-02-16 14:43 ` anemo at mba dot ocn.ne.jp 2012-02-16 14:47 ` anemo at mba dot ocn.ne.jp 2012-02-16 15:37 ` carlos at systemhalted dot org 2012-02-16 15:41 ` carlos at systemhalted dot org 2012-02-16 16:22 ` bugdal at aerifal dot cx 2012-02-16 16:35 ` carlos at systemhalted dot org 2012-02-17 5:11 ` bugdal at aerifal dot cx 2012-02-17 13:27 ` anemo at mba dot ocn.ne.jp 2012-02-17 16:18 ` carlos at systemhalted dot org 2012-02-17 16:37 ` carlos at systemhalted dot org 2012-02-20 11:42 ` anemo at mba dot ocn.ne.jp 2012-02-22 14:57 ` carlos at systemhalted dot org 2012-02-29 16:54 ` carlos at systemhalted dot org 2012-03-07 10:30 ` drepper.fsp at gmail dot com 2012-03-07 17:53 ` bugdal at aerifal dot cx 2012-03-08 3:23 ` carlos at systemhalted dot org 2012-03-08 5:13 ` bugdal at aerifal dot cx 2012-04-28 9:57 ` coolhair24 at verizon dot net 2012-06-27 22:32 ` jsm28 at gcc dot gnu.org 2012-11-29 15:55 ` carlos_odonell at mentor dot com 2012-12-01 16:43 ` aj at suse dot de 2012-12-03 23:57 ` carlos at systemhalted dot org 2013-10-09 20:14 ` neleai at seznam dot cz 2013-12-18 20:13 ` triegel at redhat dot com 2013-12-18 20:33 ` bugdal at aerifal dot cx 2013-12-18 20:49 ` bugdal at aerifal dot cx 2013-12-20 19:08 ` lopresti at gmail dot com 2013-12-20 19:38 ` carlos at redhat dot com 2013-12-20 20:25 ` triegel at redhat dot com 2013-12-20 22:51 ` bugdal at aerifal dot cx 2014-01-03 9:10 ` kevin.dempsey at aculab dot com 2014-01-06 16:58 ` triegel at redhat dot com [this message] 2014-01-06 17:46 ` lopresti at gmail dot com 2014-01-06 20:38 ` triegel at redhat dot com 2014-01-06 20:47 ` bugdal at aerifal dot cx 2014-01-06 21:20 ` triegel at redhat dot com 2014-01-06 21:24 ` bugdal at aerifal dot cx 2014-03-28 1:27 ` dancol at dancol dot org 2014-03-28 20:07 ` tudorb at gmail dot com 2014-06-20 12:23 ` kevin.dempsey at aculab dot com 2014-06-20 18:29 ` triegel at redhat dot com 2014-06-20 19:02 ` bugdal at aerifal dot cx 2014-06-20 19:10 ` bugdal at aerifal dot cx 2014-06-23 3:06 ` bugdal at aerifal dot cx 2014-06-25 14:34 ` triegel at redhat dot com 2014-06-25 16:01 ` bugdal at aerifal dot cx 2014-06-25 17:40 ` triegel at redhat dot com 2014-06-25 18:03 ` bugdal at aerifal dot cx 2014-06-27 7:26 ` fweimer at redhat dot com 2014-08-09 20:38 ` triegel at redhat dot com 2014-08-12 2:29 ` bugdal at aerifal dot cx 2015-01-15 8:45 ` mtk.manpages at gmail dot com 2015-05-30 18:25 ` dancol at dancol dot org 2015-06-03 4:08 ` carlos at redhat dot com 2015-06-03 4:09 ` carlos at redhat dot com 2015-07-14 20:23 ` triegel at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-13690-131-rjXvNjQE34@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).