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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andi Kleen <ak at linux dot jf dot intel dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org
- Date: Mon, 24 Jun 2013 17:18:15 -0400
- 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> <20130624203147 dot GO5643 at tassilo dot jf dot intel dot com>
On 06/24/2013 04:31 PM, Andi Kleen wrote:
> 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?
Yes it is a problem.
It would violate the expected semantics of the interface.
Cheers,
Carlos.