From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id 3560638555A1 for ; Tue, 7 Mar 2023 12:23:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3560638555A1 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-ed1-x52c.google.com with SMTP id cy23so51318473edb.12 for ; Tue, 07 Mar 2023 04:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678191836; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=zg0br4jJy1XW4ldbb4tJjBieHJtg861AyoRUU4hWquQ=; b=jynujgRFF+qR7rDCaDDYqvb2WdzNtcr6lmoAJigjhJ9wEGfEMWAjQnvYMq6Gs3oKP9 KO80rdu5gigJfjJg3IuRjqMq0GLyS2kQPJd0IpDdmtTvqVQqQ7Bd9TWZZNVQuYX2JYk7 J6g/A1cdxJbN30u518eANeWwOo6lUQY+mvhAV0shHHf/CjfdtjC9VNaWyNjAfB7r7FrJ t07PzvVH/CWuuRL7zYh+2WqVmydaq7omIt999VqxYZoZKlDtpwVyVx1vrezy3l7WP4HR 9U41SlZbu3lF+eK0pE+oAd5ijnKs+jEkuYNhUtQv63KhtwWZReUOD72oFQnBH90lLz2M dBqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678191836; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zg0br4jJy1XW4ldbb4tJjBieHJtg861AyoRUU4hWquQ=; b=ZhuOLTfP6lAbx5Ffi7miOQjFtJ9fpBqm3caCT2swbbvcAdEcJ+NeV8IJH8H2isI1wl fPIOmaM2cFtuy0g2PTWryOuHMCBm62Ln86vvVsKD4IHUVyVQfKNr3quzHf/GB58Si+62 pJj7+Hx1PV/zEOE13Pp4hCV0PVUNAhJb9qcnisvkEQSsaakblqN49cgnZVX+Un42S8IS yQrdxh95w9sTfqh5tthFek4Hn2RQ4F8Tg7lH01MI4OJNvLM1Jw4p9HbuIurqCCoVAr6P vM9TDerUEh8YqFcd1xGxfRPmoa597m/VPRf5+o90ot1FZhELLKYAZLvq0QaSrT1RgMD9 cqRA== X-Gm-Message-State: AO0yUKWIwuMTTFBbMTvPn+3S9YVinCl3ekpXrd4dfJEUqYshbTIFSIdj Vg4p1WqFuJThbr5e5X7uM2VdK59yMVzJv7uYElo= X-Google-Smtp-Source: AK7set8AO9djDAEnqhdrcxDmGxoZVEQ0a3hpKnmBjyHSdr1dVnL5AV6Tic3UiCAlzRdQjNQEA9n/MbpBhxgVH1vnbRk= X-Received: by 2002:a17:906:3503:b0:8b2:8876:cdd4 with SMTP id r3-20020a170906350300b008b28876cdd4mr6995449eja.7.1678191835963; Tue, 07 Mar 2023 04:23:55 -0800 (PST) MIME-Version: 1.0 From: abush wang Date: Tue, 7 Mar 2023 20:23:44 +0800 Message-ID: Subject: pthread_rwlock_rdlock return in low priority To: triegel@redhat.com, abushwang via Libc-alpha , adhemerval.zanella@linaro.org Content-Type: multipart/alternative; boundary="0000000000003f65d105f64e7cb8" X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: --0000000000003f65d105f64e7cb8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hi, Riegel 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 , and whether this posix standard should be enforced. Thanks abushwang --0000000000003f65d105f64e7cb8--