| Message ID | lhdtdc$ek0$1@ger.gmane.org |
|---|---|
| State | Committed |
| Headers |
Return-Path: <x14307373@homiemail-mx20.g.dreamhost.com> X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx20.g.dreamhost.com (mx2.sub5.homie.mail.dreamhost.com [208.113.200.128]) by wilcox.dreamhost.com (Postfix) with ESMTP id 9F35036005B for <siddhesh@wilcox.dreamhost.com>; Tue, 1 Apr 2014 01:29:55 -0700 (PDT) Received: by homiemail-mx20.g.dreamhost.com (Postfix, from userid 14307373) id 531B640AC9EA0; Tue, 1 Apr 2014 01:29:55 -0700 (PDT) X-Original-To: glibc@patchwork.siddhesh.in Delivered-To: x14307373@homiemail-mx20.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx20.g.dreamhost.com (Postfix) with ESMTPS id 31B9240BF97A9 for <glibc@patchwork.siddhesh.in>; Tue, 1 Apr 2014 01:29:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:date:message-id:mime-version :content-type; q=dns; s=default; b=F4pl6Fo/5gMgDCAR0cthDvRBb167t UjRLQ58N7/zr+f/O68GpD6KTDd+M9uaNdHfGqMj2hKW39WF2saVwXSgoejBzOPCZ S2KW99ecbIbE9yaroxFF8yU58r6cWWv5pHTC/5DzCPEVdSs+tlN5UiQczZNNGC8U RzcDTtN/gOLIo4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:from:subject:date:message-id:mime-version :content-type; s=default; bh=ohAJ1fbWX/d3CHA6vyRDzH6TTtk=; b=psn xh646itfgsmcCSpLcTosKy6U7UZWYzJ+NBLNmwx81J3oMhdGfFb/ik1jPIidSLE/ GOOwTK65b8N1tHQd2zjVE6n12/JtDdd46Nns+BVNCS49wHA+7BNAoj+/vmAkK/Ha 1KFZ9CtGiby/v9Q/5a9SmcqrQBuQLjAswWGGOJIw= Received: (qmail 12590 invoked by alias); 1 Apr 2014 08:29:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-glibc=patchwork.siddhesh.in@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 12580 invoked by uid 89); 1 Apr 2014 08:29:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: plane.gmane.org To: libc-alpha@sourceware.org From: Stefan Liebler <stli@linux.vnet.ibm.com> Subject: [PATCH] Correct mutex type check for disable lock elision via pthread_mutexattr_settype call Date: Tue, 01 Apr 2014 10:29:32 +0200 Lines: 57 Message-ID: <lhdtdc$ek0$1@ger.gmane.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------030306090500090505060706" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 X-DH-Original-To: glibc@patchwork.siddhesh.in |
Commit Message
Stefan Liebler
April 1, 2014, 8:29 a.m. UTC
Hi, if glibc is build with --enable-lock-elision=yes, all default mutexes are elided (only for supported architectures). Someone can disable the elision for one specific mutex with a call to pthread_mutexattr_settype. Currently you can specify either PTHREAD_MUTEX_NORMAL or PTHREAD_MUTEX_DEFAULT, because they are both defined to 0. The function checks for type PTHREAD_MUTEX_DEFAULT and then disables elision. For correctness, the function should check against PTHREAD_MUTEX_NORMAL! According to POSIX, PTHREAD_MUTEX_NORMAL shall deadlock if a thread tries to relock a mutex without first unlocking it. In case of PTHREAD_MUTEX_DEFAULT, the behavior is undefined. Thus the mutex can be elided with PTHREAD_MUTEX_DEFAULT, but not with PTHREAD_MUTEX_NORMAL. The same can be read in the lock elision implementation guidelines (https://sourceware.org/glibc/wiki/LockElisionGuide). Bye. --- 2014-04-01 Stefan Liebler <stli@linux.vnet.ibm.com> * nptl/pthread_mutexattr_settype.c (__pthread_mutexattr_settype): Disable lock elision for PTHREAD_MUTEX_NORMAL. ---
Comments
ping! On 04/01/2014 10:29 AM, Stefan Liebler wrote: > Hi, > > if glibc is build with --enable-lock-elision=yes, > all default mutexes are elided (only for supported architectures). > Someone can disable the elision for one specific mutex with > a call to pthread_mutexattr_settype. > Currently you can specify either PTHREAD_MUTEX_NORMAL or > PTHREAD_MUTEX_DEFAULT, because they are both defined to 0. > The function checks for type PTHREAD_MUTEX_DEFAULT > and then disables elision. > > For correctness, the function should check against PTHREAD_MUTEX_NORMAL! > According to POSIX, PTHREAD_MUTEX_NORMAL shall deadlock if a thread > tries to relock a mutex without first unlocking it. > In case of PTHREAD_MUTEX_DEFAULT, the behavior is undefined. > Thus the mutex can be elided with PTHREAD_MUTEX_DEFAULT, but not with > PTHREAD_MUTEX_NORMAL. > The same can be read in the lock elision implementation guidelines > (https://sourceware.org/glibc/wiki/LockElisionGuide). > > Bye. > > --- > 2014-04-01 Stefan Liebler <stli@linux.vnet.ibm.com> > > * nptl/pthread_mutexattr_settype.c > (__pthread_mutexattr_settype): > Disable lock elision for PTHREAD_MUTEX_NORMAL. > ---
ping. ok to commit? On 04/08/2014 02:08 PM, Stefan Liebler wrote: > ping! > On 04/01/2014 10:29 AM, Stefan Liebler wrote: >> Hi, >> >> if glibc is build with --enable-lock-elision=yes, >> all default mutexes are elided (only for supported architectures). >> Someone can disable the elision for one specific mutex with >> a call to pthread_mutexattr_settype. >> Currently you can specify either PTHREAD_MUTEX_NORMAL or >> PTHREAD_MUTEX_DEFAULT, because they are both defined to 0. >> The function checks for type PTHREAD_MUTEX_DEFAULT >> and then disables elision. >> >> For correctness, the function should check against PTHREAD_MUTEX_NORMAL! >> According to POSIX, PTHREAD_MUTEX_NORMAL shall deadlock if a thread >> tries to relock a mutex without first unlocking it. >> In case of PTHREAD_MUTEX_DEFAULT, the behavior is undefined. >> Thus the mutex can be elided with PTHREAD_MUTEX_DEFAULT, but not with >> PTHREAD_MUTEX_NORMAL. >> The same can be read in the lock elision implementation guidelines >> (https://sourceware.org/glibc/wiki/LockElisionGuide). >> >> Bye. >> >> --- >> 2014-04-01 Stefan Liebler <stli@linux.vnet.ibm.com> >> >> * nptl/pthread_mutexattr_settype.c >> (__pthread_mutexattr_settype): >> Disable lock elision for PTHREAD_MUTEX_NORMAL. >> --- > > >
ping On 04/14/2014 09:06 AM, Stefan Liebler wrote: > ping. > > ok to commit? > > On 04/08/2014 02:08 PM, Stefan Liebler wrote: >> ping! >> On 04/01/2014 10:29 AM, Stefan Liebler wrote: >>> Hi, >>> >>> if glibc is build with --enable-lock-elision=yes, >>> all default mutexes are elided (only for supported architectures). >>> Someone can disable the elision for one specific mutex with >>> a call to pthread_mutexattr_settype. >>> Currently you can specify either PTHREAD_MUTEX_NORMAL or >>> PTHREAD_MUTEX_DEFAULT, because they are both defined to 0. >>> The function checks for type PTHREAD_MUTEX_DEFAULT >>> and then disables elision. >>> >>> For correctness, the function should check against PTHREAD_MUTEX_NORMAL! >>> According to POSIX, PTHREAD_MUTEX_NORMAL shall deadlock if a thread >>> tries to relock a mutex without first unlocking it. >>> In case of PTHREAD_MUTEX_DEFAULT, the behavior is undefined. >>> Thus the mutex can be elided with PTHREAD_MUTEX_DEFAULT, but not with >>> PTHREAD_MUTEX_NORMAL. >>> The same can be read in the lock elision implementation guidelines >>> (https://sourceware.org/glibc/wiki/LockElisionGuide). >>> >>> Bye. >>> >>> --- >>> 2014-04-01 Stefan Liebler <stli@linux.vnet.ibm.com> >>> >>> * nptl/pthread_mutexattr_settype.c >>> (__pthread_mutexattr_settype): >>> Disable lock elision for PTHREAD_MUTEX_NORMAL. >>> --- >> >> >> > > >
ping On 04/23/2014 01:30 PM, Stefan Liebler wrote: > ping > On 04/14/2014 09:06 AM, Stefan Liebler wrote: >> ping. >> >> ok to commit? >> >> On 04/08/2014 02:08 PM, Stefan Liebler wrote: >>> ping! >>> On 04/01/2014 10:29 AM, Stefan Liebler wrote: >>>> Hi, >>>> >>>> if glibc is build with --enable-lock-elision=yes, >>>> all default mutexes are elided (only for supported architectures). >>>> Someone can disable the elision for one specific mutex with >>>> a call to pthread_mutexattr_settype. >>>> Currently you can specify either PTHREAD_MUTEX_NORMAL or >>>> PTHREAD_MUTEX_DEFAULT, because they are both defined to 0. >>>> The function checks for type PTHREAD_MUTEX_DEFAULT >>>> and then disables elision. >>>> >>>> For correctness, the function should check against >>>> PTHREAD_MUTEX_NORMAL! >>>> According to POSIX, PTHREAD_MUTEX_NORMAL shall deadlock if a thread >>>> tries to relock a mutex without first unlocking it. >>>> In case of PTHREAD_MUTEX_DEFAULT, the behavior is undefined. >>>> Thus the mutex can be elided with PTHREAD_MUTEX_DEFAULT, but not with >>>> PTHREAD_MUTEX_NORMAL. >>>> The same can be read in the lock elision implementation guidelines >>>> (https://sourceware.org/glibc/wiki/LockElisionGuide). >>>> >>>> Bye. >>>> >>>> --- >>>> 2014-04-01 Stefan Liebler <stli@linux.vnet.ibm.com> >>>> >>>> * nptl/pthread_mutexattr_settype.c >>>> (__pthread_mutexattr_settype): >>>> Disable lock elision for PTHREAD_MUTEX_NORMAL. >>>> --- >>> >>> >>> >> >> >> > > >
On Tue, Apr 01, 2014 at 10:29:32AM +0200, Stefan Liebler wrote: > Hi, > > if glibc is build with --enable-lock-elision=yes, > all default mutexes are elided (only for supported architectures). > Someone can disable the elision for one specific mutex with > a call to pthread_mutexattr_settype. > Currently you can specify either PTHREAD_MUTEX_NORMAL or > PTHREAD_MUTEX_DEFAULT, because they are both defined to 0. > The function checks for type PTHREAD_MUTEX_DEFAULT > and then disables elision. > > For correctness, the function should check against PTHREAD_MUTEX_NORMAL! > According to POSIX, PTHREAD_MUTEX_NORMAL shall deadlock if a thread > tries to relock a mutex without first unlocking it. > In case of PTHREAD_MUTEX_DEFAULT, the behavior is undefined. > Thus the mutex can be elided with PTHREAD_MUTEX_DEFAULT, but not > with PTHREAD_MUTEX_NORMAL. > The same can be read in the lock elision implementation guidelines > (https://sourceware.org/glibc/wiki/LockElisionGuide). > > Bye. > > --- > 2014-04-01 Stefan Liebler <stli@linux.vnet.ibm.com> > > * nptl/pthread_mutexattr_settype.c > (__pthread_mutexattr_settype): > Disable lock elision for PTHREAD_MUTEX_NORMAL. > --- > diff --git a/nptl/pthread_mutexattr_settype.c b/nptl/pthread_mutexattr_settype.c > index 0e91292..cf648cf 100644 > --- a/nptl/pthread_mutexattr_settype.c > +++ b/nptl/pthread_mutexattr_settype.c > @@ -32,7 +32,7 @@ __pthread_mutexattr_settype (attr, kind) > > /* Cannot distinguish between DEFAULT and NORMAL. So any settype > call disables elision for now. */ > - if (kind == PTHREAD_MUTEX_DEFAULT) > + if (kind == PTHREAD_MUTEX_NORMAL) > kind |= PTHREAD_MUTEX_NO_ELISION_NP; > > iattr = (struct pthread_mutexattr *) attr; Looks ok.
diff --git a/nptl/pthread_mutexattr_settype.c b/nptl/pthread_mutexattr_settype.c index 0e91292..cf648cf 100644 --- a/nptl/pthread_mutexattr_settype.c +++ b/nptl/pthread_mutexattr_settype.c @@ -32,7 +32,7 @@ __pthread_mutexattr_settype (attr, kind) /* Cannot distinguish between DEFAULT and NORMAL. So any settype call disables elision for now. */ - if (kind == PTHREAD_MUTEX_DEFAULT) + if (kind == PTHREAD_MUTEX_NORMAL) kind |= PTHREAD_MUTEX_NO_ELISION_NP; iattr = (struct pthread_mutexattr *) attr;