From patchwork Sat Jan 16 20:49:47 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Malte Skarupke X-Patchwork-Id: 41731 X-Patchwork-Delegate: carlos@redhat.com Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 038653846047; Sat, 16 Jan 2021 20:50:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 038653846047 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610830211; bh=Tvtc5fKWhSISsj9Yh4d2R6VSpkqocWXFB8Z/S2+sCbQ=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Hz9DWHT+swajQDI1p14cl623eNpfjaIZ90SQuEPNwQtp5c4DfPOCwMx8BBolCA+Gr cH68AGbLfwAq9mIJjAJ9KS9NxU5ayCh7fZQ+MIRAxkRA9FT+IWECzDyR3f4lesGkiY u+ToMzXpQZH4kmpsC070mXPGyw1fXkLuBUiH0isU= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mout.web.de (mout.web.de [212.227.17.12]) by sourceware.org (Postfix) with ESMTPS id 95665388A407 for ; Sat, 16 Jan 2021 20:50:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 95665388A407 X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from auth1-smtp.messagingengine.com ([66.111.4.227]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MMVu6-1l81eb1VVe-008HEP; Sat, 16 Jan 2021 21:49:59 +0100 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 99A3B27C005B; Sat, 16 Jan 2021 15:49:57 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 16 Jan 2021 15:49:57 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdeggddugeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgjfhestddtredtre dttdenucfhrhhomhepofgrlhhtvgcuufhkrghruhhpkhgvuceomhgrlhhtvghskhgrrhhu phhkvgesfigvsgdruggvqeenucggtffrrghtthgvrhhnpeduffeufedtudehhfffieejfe ehfeefledvffffffehhfefffelffeiudelteehfeenucfkphepieejrddvheegrdduieeh rdelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh grlhhtvghskhgrrhhuphhkvgdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidq uddtudejtdefvdeliedqudduvdegvdekieelqdhmrghlthgvshhkrghruhhpkhgvpeepfi gvsgdruggvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: from localhost.localdomain (unknown [67.254.165.9]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E8AA108005C; Sat, 16 Jan 2021 15:49:57 -0500 (EST) To: libc-alpha@sourceware.org Subject: [PATCH 2/5] nptl: Remove the signal-stealing code. It is no longer needed. Date: Sat, 16 Jan 2021 15:49:47 -0500 Message-Id: <20210116204950.16434-2-malteskarupke@web.de> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210116204950.16434-1-malteskarupke@web.de> References: <20210116204950.16434-1-malteskarupke@web.de> X-Provags-ID: V03:K1:N0In6E6eRk8gcjW5klB6jg+RFcbk8Aroj4SlxazBpGTPlfI/zxp 2Rh4n8hF8A3usSvEN1NHqkq/GxUdBBa+s5G7LcSZi2xvT7hdmp6Oag0S6R9BWgFJQio59px AfwICTYkY6+inWYx1X/gzODQlFk85U+6xYetQt19Q1cLxmztQ3n0Xei0boCTlDe0yohJY31 yV2bNjermj8PFFB47SgPw== X-UI-Out-Filterresults: notjunk:1;V03:K0:NPtFl+O6au8=:sx4DgC6DSsei+q+hQakESD EMIH/s6PAi00b4eqXPMwqo3IO0nPRSUDoYhaMh1SRotZsYKv60Gq20+YRBdBJeaQe/KitLEW4 zx+8mvyX1wtk7Sjrtgj/7G9gNwVJHij9QiTuzC3bK8MLwYCTdhqntF8b/YPnd8hlFrFNk8BIE FaGXLo2xzhxpeU3NUL/9rMrcDehaje1I78i7vSKghu3+kXvzm8JUVXjrgOTUg74DK1Jgc44HN ERr9A/FoopHirgtOpLsbYJmwkG6FFaw4BLBG+M5YErJzXPerm+XI3X3Ia+mImsfTXJZQGjPtm zyRMARDBXSw+CG1kyrshsPIeCvehKtBV+rfaFLLADp4ejokPTJYuK5TFUbkwo1MCyYAf5N6L8 bnQWmNJ9bKcSsraVSrb7GYjSZttaQKEleQUJcBPZ9Mh3CZzPHnkidTduo2B8K3TX6tkji57UN EFN1dps/kYmnmqBLWi7eQRctEnP5Bx0eNopH2Cs1v104RLCEGyAJtB144p/Bu8Enwzm8fD+A1 KgmNcPKl/qxSH4p+jL9dxVrVcNDwV39xoetbwsvXSTH3pPMnruxkdpFYLw0pON/pYoUxr9vpo +N1BgNDN4SNNeu+4wUXuG6jSDF75onWb+DicPBlvz0hjlL9oZAUpy51rUh72cpOgsjyF5AkDl 9ohvzbt9jUJRcqggWt053F2J83tLpgHlRKsXQm4NA/BfQcUsantOvoU35hkOuRVdUKrABdP60 a+4Tuz1Ze2vYksSDU3cG4DkHs8TYosHLc5C5NTGx+a0PToHK5LItipKqOq7uNPnNXGvpbm5iB VJLEWPlSTQLBmC2M8q6DYvE5dEoh0QDfKCH+llm8Wth088e+Ycp3/bFxKLik3zpIg/oYdT5PT AEySevOmC/wVPa0YyTgw== X-Spam-Status: No, score=-13.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Malte Skarupke via Libc-alpha From: Malte Skarupke Reply-To: Malte Skarupke Cc: Malte Skarupke , triegel@redhat.com, malteskarupke@fastmail.fm Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" After my last change, stealing of signals can no longer happen. This patch removes the code that handled the case when a signal was stolen. --- nptl/pthread_cond_wait.c | 63 ---------------------------------------- 1 file changed, 63 deletions(-) -- 2.17.1 diff --git a/nptl/pthread_cond_wait.c b/nptl/pthread_cond_wait.c index 0f50048c0b..7b825f81df 100644 --- a/nptl/pthread_cond_wait.c +++ b/nptl/pthread_cond_wait.c @@ -525,69 +525,6 @@ __pthread_cond_wait_common (pthread_cond_t *cond, pthread_mutex_t *mutex, while (!atomic_compare_exchange_weak_acquire (cond->__data.__g_signals + g, &signals, signals - 2)); - /* We consumed a signal but we could have consumed from a more recent group - that aliased with ours due to being in the same group slot. If this - might be the case our group must be closed as visible through - __g1_start. */ - uint64_t g1_start = __condvar_load_g1_start_relaxed (cond); - if (seq < (g1_start >> 1)) - { - /* We potentially stole a signal from a more recent group but we do not - know which group we really consumed from. - We do not care about groups older than current G1 because they are - closed; we could have stolen from these, but then we just add a - spurious wake-up for the current groups. - We will never steal a signal from current G2 that was really intended - for G2 because G2 never receives signals (until it becomes G1). We - could have stolen a signal from G2 that was conservatively added by a - previous waiter that also thought it stole a signal -- but given that - that signal was added unnecessarily, it's not a problem if we steal - it. - Thus, the remaining case is that we could have stolen from the current - G1, where "current" means the __g1_start value we observed. However, - if the current G1 does not have the same slot index as we do, we did - not steal from it and do not need to undo that. This is the reason - for putting a bit with G2's index into__g1_start as well. */ - if (((g1_start & 1) ^ 1) == g) - { - /* We have to conservatively undo our potential mistake of stealing - a signal. We can stop trying to do that when the current G1 - changes because other spinning waiters will notice this too and - __condvar_quiesce_and_switch_g1 has checked that there are no - futex waiters anymore before switching G1. - Relaxed MO is fine for the __g1_start load because we need to - merely be able to observe this fact and not have to observe - something else as well. - ??? Would it help to spin for a little while to see whether the - current G1 gets closed? This might be worthwhile if the group is - small or close to being closed. */ - unsigned int s = atomic_load_relaxed (cond->__data.__g_signals + g); - while (__condvar_load_g1_start_relaxed (cond) == g1_start) - { - /* Try to add a signal. We don't need to acquire the lock - because at worst we can cause a spurious wake-up. If the - group is in the process of being closed (LSB is true), this - has an effect similar to us adding a signal. */ - if (((s & 1) != 0) - || atomic_compare_exchange_weak_relaxed - (cond->__data.__g_signals + g, &s, s + 2)) - { - /* If we added a signal, we also need to add a wake-up on - the futex. We also need to do that if we skipped adding - a signal because the group is being closed because - while __condvar_quiesce_and_switch_g1 could have closed - the group, it might stil be waiting for futex waiters to - leave (and one of those waiters might be the one we stole - the signal from, which cause it to block using the - futex). */ - futex_wake (cond->__data.__g_signals + g, 1, private); - break; - } - /* TODO Back off. */ - } - } - } - done: /* Confirm that we have been woken. We do that before acquiring the mutex