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/25847] pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing Date: Fri, 25 Dec 2020 16:19:07 +0000 [thread overview] Message-ID: <bug-25847-131-hmYHtWSiCC@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-25847-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=25847 --- Comment #18 from Torvald Riegel <triegel at redhat dot com> --- (In reply to Qin Li from comment #0) > As the G1 might still have several remaining waiters, when new signals come, > waiters from this damaged G1 will still be woke up. Until the last signal is > delivered on this G1, we would observe what was shown in the dump above: > that we posted a signal to a G1, no futex waiter woke up, as __g_refs[G1] > was already 0 before __g_size[G1] did, and the signal remains not taken. But > in the meantime there are one or more waiters in G2. Signal is lost, when > indeed we could have wake up a waiter in G2. Qin Li, thank you for investigating, isolating the issue, and providing the reproducer. I agree that there is a bug in that just incrementing a group's number of available signals isn't sufficient because it doesn't adjust the group size (ie, the number of waiters that signalers think are still in this group) accordingly. The result is that signalers can put a correct signal in a group that is already effectively empty even though it's size doesn't show that, which leads to this signal being "lost". __condvar_cancel_waiting also updates group size, for example. I also think that a solution would be to handle potential stealing in such a way that it takes all the steps a pthread_cond_signal would, so including updating the group's size. I believe we don't need a full broadcast for that, which would reset everything basically. Malte Skarupke's proposed solution of "locking" groups through __g_refs more broadly could also work in principle. I'll respond to the patch directly on libc-alpha. I'm wondering about the performance implications of this approach, even though a full pthread_cond_signal could also be costly because it adds contention to signalers. (In reply to Torvald Riegel from comment #17) > (I'm aware of the first > reproducer posted, but I'm currently looking at it and am not yet convinced > that it is correct; it sends out more signals than the number of wake-ups it > allows through the wait condition, AFAICT, which I find surprising.) I haven't fully wrapped my head around how the critical section implementation covered in the reproducer works, but I also don't see any concrete red flags anymore. What had me surprised is that it really depends on blocking through the condvar, which I'd say is different from how many concurrent algorithms treat blocking through OS facilities like futexes as "optional" because the real functional blocking happens through shared-memory synchronization. Second, the AWAKENED_WAITER flag seems to be intended to leak into the waiter ref count (ie, you can't have the waiter ref count start at a higher bit, the "overflow" of the flag seems to be intended). -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2020-12-25 16:19 UTC|newest] Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-18 8:04 [Bug nptl/25847] New: " qin.li at thetradedesk dot com 2020-04-18 8:07 ` [Bug nptl/25847] " qin.li at thetradedesk dot com 2020-04-20 17:52 ` qin.li at thetradedesk dot com 2020-05-05 11:50 ` arun11299 at gmail dot com 2020-05-05 11:52 ` arun11299 at gmail dot com 2020-05-14 8:52 ` dingxiangfei2009 at protonmail dot ch 2020-05-19 21:15 ` carlos at redhat dot com 2020-10-08 19:07 ` michael.bacarella at gmail dot com 2020-10-10 8:11 ` flo at geekplace dot eu 2020-10-12 20:53 ` anssi.hannula at iki dot fi 2020-10-13 16:50 ` guillaume at morinfr dot org 2020-10-16 20:23 ` kirichenkoga at gmail dot com 2020-10-18 22:55 ` michael.bacarella at gmail dot com 2020-10-20 20:12 ` kirichenkoga at gmail dot com 2020-10-20 20:17 ` kirichenkoga at gmail dot com 2020-11-01 13:58 ` malteskarupke at fastmail dot fm 2020-11-01 15:40 ` michael.bacarella at gmail dot com 2020-11-15 2:45 ` malteskarupke at fastmail dot fm 2020-11-23 10:37 ` ydroneaud at opteya dot com 2020-11-23 16:36 ` mattst88 at gmail dot com 2020-11-23 16:46 ` adhemerval.zanella at linaro dot org 2020-12-07 15:41 ` balint at balintreczey dot hu 2020-12-09 3:22 ` malteskarupke at fastmail dot fm 2020-12-24 20:02 ` triegel at redhat dot com 2020-12-25 16:19 ` triegel at redhat dot com [this message] 2021-01-07 1:09 ` manojgupta at google dot com 2021-01-07 7:31 ` balint at balintreczey dot hu 2021-01-07 13:54 ` malteskarupke at fastmail dot fm 2021-01-07 20:43 ` triegel at redhat dot com 2021-01-07 23:31 ` triegel at redhat dot com 2021-01-08 3:45 ` malteskarupke at fastmail dot fm 2021-01-16 0:21 ` triegel at redhat dot com 2021-01-16 0:23 ` triegel at redhat dot com 2021-01-30 0:59 ` michael.bacarella at gmail dot com 2021-02-07 17:38 ` slav.isv at gmail dot com 2021-03-09 15:18 ` bugdal at aerifal dot cx 2021-04-06 0:37 ` frankbarrus_sw at shaggy dot cc 2021-04-06 1:17 ` frankbarrus_sw at shaggy dot cc 2021-04-06 14:32 ` frankbarrus_sw at shaggy dot cc 2021-04-06 16:49 ` frankbarrus_sw at shaggy dot cc 2021-04-11 12:12 ` carlos at redhat dot com 2021-04-11 12:13 ` carlos at redhat dot com 2021-04-13 12:21 ` frankbarrus_sw at shaggy dot cc 2021-04-14 16:57 ` qin.li at thetradedesk dot com 2021-04-15 14:13 ` frankbarrus_sw at shaggy dot cc 2021-04-15 14:34 ` frankbarrus_sw at shaggy dot cc 2021-04-30 17:41 ` venkiram_be at yahoo dot co.in 2021-05-04 22:48 ` frankbarrus_sw at shaggy dot cc 2021-05-04 22:51 ` frankbarrus_sw at shaggy dot cc 2021-05-04 22:58 ` frankbarrus_sw at shaggy dot cc 2021-05-13 13:25 ` tuliom at ascii dot art.br 2021-06-14 13:31 ` willireamangel at gmail dot com 2021-07-09 1:41 ` uwydoc at gmail dot com 2021-07-15 0:55 ` benh at kernel dot crashing.org 2021-08-16 9:41 ` evgeny+sourceware at loop54 dot com 2021-09-13 16:50 ` dushistov at mail dot ru 2021-09-22 19:03 ` evgeny+sourceware at loop54 dot com 2021-09-22 19:07 ` balint at balintreczey dot hu 2021-09-24 0:18 ` tuliom at ascii dot art.br 2021-09-24 0:58 ` michael.bacarella at gmail dot com 2021-09-29 11:50 ` fweimer at redhat dot com 2021-10-21 15:42 ` fweimer at redhat dot com 2021-10-30 22:17 ` sam at gentoo dot org 2021-11-25 14:49 ` arekm at maven dot pl 2022-09-18 5:38 ` malteskarupke at fastmail dot fm 2022-09-18 20:06 ` carlos at redhat dot com 2022-09-19 3:38 ` malteskarupke at fastmail dot fm 2022-09-24 0:03 ` bugzilla at dimebar dot com 2022-09-24 10:15 ` ismail at i10z dot com 2022-09-26 14:28 ` ehagberg at janestreet dot com 2022-09-26 14:32 ` ehagberg at janestreet dot com 2022-10-06 21:58 ` malteskarupke at fastmail dot fm 2022-10-07 12:01 ` crrodriguez at opensuse dot org 2022-10-15 19:57 ` malteskarupke at fastmail dot fm 2022-11-07 18:23 ` sourceware-bugzilla at djr61 dot uk 2023-01-28 14:57 ` malteskarupke at fastmail dot fm 2023-05-01 12:52 ` carlos at redhat dot com 2023-05-02 12:57 ` carlos at redhat dot com 2023-05-03 3:04 ` malteskarupke at fastmail dot fm 2023-05-04 4:57 ` malteskarupke at fastmail dot fm 2023-05-04 12:24 ` carlos at redhat dot com 2023-05-05 23:44 ` carlos at redhat dot com 2023-05-10 21:29 ` frankbarrus_sw at shaggy dot cc 2023-05-10 21:39 ` frankbarrus_sw at shaggy dot cc 2023-05-11 0:22 ` frankbarrus_sw at shaggy dot cc 2023-05-11 12:01 ` carlos at redhat dot com 2023-05-11 12:05 ` carlos at redhat dot com 2023-05-13 4:10 ` malteskarupke at fastmail dot fm 2023-08-24 20:24 ` jwakely.gcc at gmail dot com 2023-09-26 12:33 ` malteskarupke at fastmail dot fm 2023-09-26 12:38 ` fweimer at redhat dot com 2024-01-05 7:31 ` malteskarupke at fastmail dot fm 2024-02-17 9:44 ` github at kalvdans dot no-ip.org
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-25847-131-hmYHtWSiCC@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).