From patchwork Tue Mar 7 03:50:30 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: abushwang X-Patchwork-Id: 66063 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 892DD3854833 for ; Tue, 7 Mar 2023 03:51:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 892DD3854833 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678161062; bh=6nWMDUKZFsWhK/7F/kdzYWmHtStSRu+kZIN/EPuHj40=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=JYyzslCdmNIlSTjCeD4+22bLiVCnQVLNOmAX97uwK+m5J/ZTNKIFJwPQ2fWpnsP2/ OFbt1iT2xMFkY3+vsiRDaxnBTdBXIvLbWMbayzS8gae7sOCR011l7uEt69fI9ciAou aCrjj/limUVZU78kzruihysyGuygpgTCshL2COo8= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id CC9DA3858D39 for ; Tue, 7 Mar 2023 03:50:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CC9DA3858D39 Received: by mail-pl1-x635.google.com with SMTP id p20so12724417plw.13 for ; Mon, 06 Mar 2023 19:50:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678161036; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6nWMDUKZFsWhK/7F/kdzYWmHtStSRu+kZIN/EPuHj40=; b=hd7EzuV/mQahUaU7kxZAZLY03nZOyzbKKOfGsxNBgHOY3KPmPC2lsTeAUBdpigxANg 1ydXyIe14wjC92FjQrdiJITDZEAEUBCe0AXrSGYFaT0DvibC7KEoVwO53Mv2/nljjHhD 0MFD/v+clpBqxN/oAp1JoxW7kTURXII+MvlQJx5pqiobY01Q5dcFcG/+niaKOhHlLMgt WucMxltxxmvNmn/YHpcLWcPDYl6DD0uCtH+zIC1Cze0I9u7O5S7YwVI1spxWw23qf2Fi 9R4IGy0xgnC9SMHBuKPSWyT9JFKiWzIvhPE413xgZROV2kYG8dLC4PaQGSFxr3wawcyx a4mg== X-Gm-Message-State: AO0yUKVVhh5Zt7uOVxW3pMixziFNM7MU7a4HMrciiWwSOnFU0nKjPcMa QGfU6u6XYkN+uimyuIr1UHODev8iQqGe9w== X-Google-Smtp-Source: AK7set/DWTX5tIV25tZBHJqu6gMjErRZMjqKvbWuGuoSaTckglwnLf4dA7fGe5FqWQJXRbOnDX8eTw== X-Received: by 2002:a17:903:1c1:b0:19d:553:745c with SMTP id e1-20020a17090301c100b0019d0553745cmr13011615plh.9.1678161035930; Mon, 06 Mar 2023 19:50:35 -0800 (PST) Received: from localhost.localdomain ([43.132.141.9]) by smtp.gmail.com with ESMTPSA id kx7-20020a170902f94700b001990028c0c9sm7470684plb.68.2023.03.06.19.50.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Mar 2023 19:50:34 -0800 (PST) To: libc-alpha@sourceware.org, drepper.fsp@gmail.com Cc: abushwang Subject: [PATCH] nptl: pthread_rwlock_rdlock return in low priority Date: Tue, 7 Mar 2023 11:50:30 +0800 Message-Id: <20230307035030.437573-1-abushwangs@gmail.com> X-Mailer: git-send-email 2.36.1 MIME-Version: 1.0 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: abushwang via Libc-alpha From: abushwang Reply-To: abushwang Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" hi, I have noticed reader will return directly on fast-path in pthread_rwlock_common.c > /* We have registered as a reader, so if we are in a read phase, we have > acquired a read lock. This is also the reader--reader fast-path. > Even if there is a primary writer, we just return. If writers are to > be preferred and we are the only active reader, we could try to enter a > write phase to let the writer proceed. This would be okay because we > cannot have acquired the lock previously as a reader (which could result > in deadlock if we would wait for the primary writer to run). However, > this seems to be a corner case and handling it specially not be worth the > complexity. */ > if (__glibc_likely ((r & PTHREAD_RWLOCK_WRPHASE) == 0)) > return 0; However, there is a situation: main, thread_wr, thread_rd. SCHED_FIFO priority: main > thread_wr > thread_rd main first acquires read lock, then create thread_wr which will block on the lock. Next, main creates thread_rd. this thread will acquires read lock on fast-path even though it has a lower priority compared to thread_wr. You can get demo from the following repository: https://github.com/emscripten-core/posixtestsuite.git ./conformance/interfaces/pthread_rwlock_rdlock/2-1.c According to "man -M man-pages-posix-2017/ 3p pthread_rwlock_rdlock" > DESCRIPTION > The pthread_rwlock_rdlock() function shall apply a read lock to the > read-write lock referenced by rwlock. The calling thread acquires the > read lock if a writer does not hold the lock and there are no > writers blocked on the lock. > > If the Thread Execution Scheduling option is supported, and the > threads involved in the lock are executing with the scheduling > policies SCHED_FIFO or SCHED_RR, the calling thread shall not acquire > the lock if a writer holds the lock or if writers of higher or equal > priority are blocked on the lock; other‐ wise, the calling thread > shall acquire the lock. I was wondering that whether this fast-path is reasonable, and whether this posix standard should be enforced. Thanks Signed-off-by: abushwang --- nptl/pthread_rwlock_common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/nptl/pthread_rwlock_common.c b/nptl/pthread_rwlock_common.c index 5266a00ed1..35b00fc14f 100644 --- a/nptl/pthread_rwlock_common.c +++ b/nptl/pthread_rwlock_common.c @@ -389,6 +389,7 @@ __pthread_rwlock_rdlock_full64 (pthread_rwlock_t *rwlock, clockid_t clockid, complexity. */ if (__glibc_likely ((r & PTHREAD_RWLOCK_WRPHASE) == 0)) return 0; + /* Otherwise, if we were in a write phase (states #6 or #8), we must wait for explicit hand-over of the read phase; the only exception is if we can start a read phase if there is no primary writer currently. */