From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1]) by sourceware.org (Postfix) with ESMTPS id 8C5E43858C39 for ; Tue, 7 Mar 2023 17:09:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8C5E43858C39 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1678208965; bh=Xj6oO7zDa5uT59iMk+i09zwIT0cukWsLX+R5clVbV60=; h=Subject:From:To:Date:In-Reply-To:References:From; b=fBvOCkRtar/3qYRYxBJRUiZPZJqjL/g2B2zoGLDIBf4onvvHKs2MedZe/uVERXu2d Y3EwicN5oE9boMw3RuvE7BdXOjPe60HhB9yx8mq40qae1/Spvf/NoElRXji4neJQOq UEzsoYhsjZqP78vI07y8BQPtLPIq3AR15DZwX6yg= Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id DD8DC65C26; Tue, 7 Mar 2023 12:09:24 -0500 (EST) Message-ID: <9189dfbb27c425d89cf490008699dc3a5d3f39e0.camel@xry111.site> Subject: Re: pthread_rwlock_rdlock return in low priority From: Xi Ruoyao To: abush wang , triegel@redhat.com, abushwang via Libc-alpha , adhemerval.zanella@linaro.org Date: Wed, 08 Mar 2023 01:09:23 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 2023-03-07 at 20:23 +0800, abush wang via Libc-alpha wrote: > hi, Riegel >=20 > I have noticed reader will return directly on fast-path in > pthread_rwlock_common.c >=20 > > *=C2=A0 /* We have registered as a reader, so if we are in a read phase= , we have > *>*=C2=A0=C2=A0=C2=A0=C2=A0 acquired a read lock.=C2=A0 This is also the = reader--reader fast-path. > *>*=C2=A0=C2=A0=C2=A0=C2=A0 Even if there is a primary writer, we just re= turn.=C2=A0 If writers are to > *>*=C2=A0=C2=A0=C2=A0=C2=A0 be preferred and we are the only active reade= r, we could try to enter a > *>*=C2=A0=C2=A0=C2=A0=C2=A0 write phase to let the writer proceed.=C2=A0 = This would be okay because we > *>*=C2=A0=C2=A0=C2=A0=C2=A0 cannot have acquired the lock previously as a= reader (which could result > *>*=C2=A0=C2=A0=C2=A0=C2=A0 in deadlock if we would wait for the primary = writer to run).=C2=A0 However, > *>*=C2=A0=C2=A0=C2=A0=C2=A0 this seems to be a corner case and handling i= t specially not > be worth the > *>*=C2=A0=C2=A0=C2=A0=C2=A0 complexity.=C2=A0 */ > *>*=C2=A0 if (__glibc_likely ((r & PTHREAD_RWLOCK_WRPHASE) =3D=3D 0)) > *>*=C2=A0=C2=A0=C2=A0 return 0; > * > However, there is a situation: > =C2=A0=C2=A0=C2=A0 main, thread_wr, thread_rd. >=20 > =C2=A0=C2=A0=C2=A0 SCHED_FIFO priority: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 main > thread_wr > thread_rd > =C2=A0=C2=A0=C2=A0 main first acquires read lock, then create thread_wr w= hich will > block on the lock. > =C2=A0=C2=A0=C2=A0 Next, main creates thread_rd. this thread will acquire= s read lock > on fast-path even > =C2=A0=C2=A0=C2=A0 though it has a lower priority compared to thread_wr. >=20 > You can get demo from the following > repository:https://github.com/emscripten-core/posixtestsuite.git > ./conformance/interfaces/pthread_rwlock_rdlock/2-1.c >=20 > According to "man -M man-pages-posix-2017/ 3p pthread_rwlock_rdlock" >=20 > > * DESCRIPTION > *>* The pthread_rwlock_rdlock() function shall apply a read lock to the > *>* read-write lock referenced by rwlock.=C2=A0 The calling thread acquir= es the > *>* read lock=C2=A0 if=C2=A0 a writer does not hold the lock and there ar= e no > *>* writers blocked on the lock. > *>>* If=C2=A0 the=C2=A0 Thread=C2=A0 Execution=C2=A0 Scheduling=C2=A0 opt= ion=C2=A0 is supported,=C2=A0 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;=C2=A0 other=E2=80=90 wise, the call= ing thread > *>* shall acquire the lock. > * > I was wondering that whether this >=20 > , and whether > this posix standard should be enforced. Already declared as WONTFIX several years ago: https://sourceware.org/bugzilla/show_bug.cgi?id=3D13701. And a more general ticket about "POSIX violations in corner cases": https://sourceware.org/bugzilla/show_bug.cgi?id=3D25619. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University