This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- From: Andi Kleen <ak at linux dot jf dot intel dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot jf dot intel dot com>
- Date: Mon, 24 Jun 2013 13:31:47 -0700
- Subject: Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- References: <1372105055-31254-1-git-send-email-andi at firstfloor dot org> <51C8AB50 dot 80108 at redhat dot com>
On Mon, Jun 24, 2013 at 04:25:52PM -0400, Carlos O'Donell wrote:
> On 06/24/2013 04:17 PM, Andi Kleen wrote:
> > From: Andi Kleen <ak@linux.intel.com>
> >
> > Carlos asked for PTHREAD_MUTEX_NORMAL_INT to be added
> > to make some of the internal macros be easier to understand.
> > It is always identical to DEFAULT, as NORMAL only makes
> > a difference for settype.
>
> Thanks for this.
>
> As it stands however, with pthread_mutexattr_gettype loosing
> the type originally entered by the user, we are going to have to
> propagate the new type internally.
It will return DEFAULT|NO_ELISION, which is identical in behaviour
to NORMAL
So if you do
settype(&a, NORMAL);
settype(&b, gettype(&a));
it will all work as expected. Even b will have all NORMAL semantics.
The only case that wouldn't work is someone explicitely rechecking
the value returned by gettype(). Is that really a problem?
-Andi