From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22052 invoked by alias); 24 Oct 2016 17:08:58 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 22029 invoked by uid 89); 24 Oct 2016 17:08:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=1028, libc_probe, LIBC_PROBE, __elide_unlock X-HELO: mx1.redhat.com Message-ID: <1477328930.7146.81.camel@localhost.localdomain> Subject: Re: [PATCH] Document a behavior of an elided pthread_rwlock_unlock From: Torvald Riegel To: Tulio Magno Quites Machado Filho Cc: libc-alpha@sourceware.org Date: Mon, 24 Oct 2016 17:08:00 -0000 In-Reply-To: <1477083990-9983-1-git-send-email-tuliom@linux.vnet.ibm.com> References: <1477083990-9983-1-git-send-email-tuliom@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00395.txt.bz2 On Fri, 2016-10-21 at 19:06 -0200, Tulio Magno Quites Machado Filho wrote: > Explain that pthread_rwlock_unlock may crash if called on a lock not > held by the current thread. > > 2016-10-21 Tulio Magno Quites Machado Filho > > * nptl/pthread_rwlock_unlock.c: Add a comment explaining its > behavior when eliding a lock not held by the current thread. > * sysdeps/powerpc/nptl/elide.h: Likewise. > --- > nptl/pthread_rwlock_unlock.c | 4 ++++ > sysdeps/powerpc/nptl/elide.h | 2 ++ > 2 files changed, 6 insertions(+) > > diff --git a/nptl/pthread_rwlock_unlock.c b/nptl/pthread_rwlock_unlock.c > index a6cadd4..112f748 100644 > --- a/nptl/pthread_rwlock_unlock.c > +++ b/nptl/pthread_rwlock_unlock.c > @@ -35,6 +35,10 @@ __pthread_rwlock_unlock (pthread_rwlock_t *rwlock) > > LIBC_PROBE (rwlock_unlock, 1, rwlock); > > + /* Trying to elide an unlocked lock may crash the process. This > + is expected and is compatible with POSIX.1-2008: "results are > + undefined if the read-write lock rwlock is not held by the > + calling thread". */ > if (ELIDE_UNLOCK (rwlock->__data.__writer == 0 > && rwlock->__data.__nr_readers == 0)) > return 0; > diff --git a/sysdeps/powerpc/nptl/elide.h b/sysdeps/powerpc/nptl/elide.h > index 77bd82e..c573981 100644 > --- a/sysdeps/powerpc/nptl/elide.h > +++ b/sysdeps/powerpc/nptl/elide.h > @@ -102,6 +102,8 @@ __elide_unlock (int is_lock_free) > { > if (is_lock_free) > { > + /* Intentionally crashes when trying to unlock a lock not held by this > + thread. */ I'd rather say that this can happen, and is okay (refering to the comment in pthread_rwlock_unlock.c). Otherwise, LGTM. > __libc_tend (0); > return true; > }