From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by sourceware.org (Postfix) with ESMTPS id 9E7913858D39 for ; Tue, 7 Mar 2023 11:38:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9E7913858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yb1-xb35.google.com with SMTP id v101so11061726ybi.2 for ; Tue, 07 Mar 2023 03:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678189134; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=plCdHYJsXfm3+roY/bUXgXE8prQ6wBpZ2o7fVC7HnqM=; b=h1XcUT6/XWOwnFnWTSoxCipRtgIfu5+KDMX14nXpXLAsLl8kKrl9Q+985qjebZDNIr RRlJz+A55D+UjIYPFa8NbMfrPC4s6e1ktDvaboGJ3B88HQo4/2A4qS5x9bECMF7jJgO5 y1RSNW5dA30+tGZpbVZZlyy0y3hfSkJqPS/UwYv/i5Z+5CAaRZsF55dTe4l+5nsaj0Dh 8dHfjri5A/I59Tur4g8thZxxexgwWFsolVZ9AX6dKsfi91voFpAnfVzhDowCOVfS3fsw jq+aKjnak5Ph2W6o+L03JvWOKh6LY2q8HqkCJpq2fUbzivBvuijx8hmh450sbSJnBIJn 5IwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678189134; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=plCdHYJsXfm3+roY/bUXgXE8prQ6wBpZ2o7fVC7HnqM=; b=BRHNRLZAClKAfyAbwCwtTX4SoY+1j06VMFxHk+1Elqe0Er4Jmt0otbS0XngG28bzuc /BFsqDKwSOp7f4SQ1NmA2RgpGR3rti9lRzTd/fvYPk/lI0Q8S6utSKEVaFq/lqIYU1Rx 0s/sBpSUqcTbZYcebs4MgiTifu5pgPOV8+a2r2xEqmSw8HuyRAh7SLMy1R7Ep7gBxSmB 1x1hNATJnk59dmQIaoPAx+xKuv1qjHTUQuvCSNv+1b7/GGWn7O0g+ODcm1nPj4pVqAm7 gJUq1peUDgLliq/YQYRIvlAMojamxG+VzjT6xGFIxxEJHiAq0n8CGlA1fpKLHnnyk1oQ EG0A== X-Gm-Message-State: AO0yUKV3sJdl7j/ds03R41A9hF/IbyJ4AG/kpgR0/Brr7/j43CRRpX5/ mb038aehVADP5AbCdfwKu0SgLQB9BDRQ0J42NmIT2gQ4lKP19w== X-Google-Smtp-Source: AK7set83KsehtNQoNWAojKwdqms7SPBmLsjgjRwtXiH05VodjeCdHco/LbKahRdkJPQtTV6zQRD9d2+s/h65vhoazu4= X-Received: by 2002:a05:6902:185:b0:acd:7374:f15b with SMTP id t5-20020a056902018500b00acd7374f15bmr8517661ybh.13.1678189133904; Tue, 07 Mar 2023 03:38:53 -0800 (PST) MIME-Version: 1.0 From: abush wang Date: Tue, 7 Mar 2023 19:38:41 +0800 Message-ID: Subject: [PATCH v2] nptl: pthread_rwlock_rdlock return in low priority To: drepper.fsp@gmail.com, abushwang via Libc-alpha Content-Type: multipart/alternative; boundary="00000000000031404805f64ddb64" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GB_TO_NAME_FREEMAIL,HTML_MESSAGE,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 List-Id: --00000000000031404805f64ddb64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (*This is just a mail for advisory*) 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 ent= er 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 r= esult *>* in deadlock if we would wait for the primary writer to run). Howev= er, *>* this seems to be a corner case and handling it specially not be worth the *>* complexity. */ *>* if (__glibc_likely ((r & PTHREAD_RWLOCK_WRPHASE) =3D=3D 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=E2=80=90 wise, the calling thr= ead *>* shall acquire the lock. * I was wondering that whether this fast-path is reasonable, and whether this posix standard should be enforced. Thanks --00000000000031404805f64ddb64--