This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH][BZ #15790] Have pthread_mutexattr_gettype mask out the elision bit.
- From: Cesar Philippidis <cesar at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Andi Kleen <andi at firstfloor dot org>, OndÅej BÃlka <neleai at seznam dot cz>, <libc-alpha at sourceware dot org>
- Date: Wed, 13 Nov 2013 10:41:44 -0800
- Subject: Re: [PATCH][BZ #15790] Have pthread_mutexattr_gettype mask out the elision bit.
- Authentication-results: sourceware.org; auth=none
- References: <5266B4C3 dot 3090106 at codesourcery dot com> <20131107121529 dot GA17527 at domone> <20131107175715 dot GM29695 at two dot firstfloor dot org> <20131108041730 dot GY24286 at brightrain dot aerifal dot cx> <5281007C dot 7030201 at codesourcery dot com> <20131111174905 dot GL24286 at brightrain dot aerifal dot cx> <52812296 dot 1040405 at codesourcery dot com> <20131111185631 dot GM24286 at brightrain dot aerifal dot cx>
On 11/11/13, 10:56 AM, Rich Felker wrote:
> On Mon, Nov 11, 2013 at 10:31:50AM -0800, Cesar Philippidis wrote:
>> On 11/11/13, 9:49 AM, Rich Felker wrote:
>>> On Mon, Nov 11, 2013 at 08:06:20AM -0800, Cesar Philippidis wrote:
>>>> On 11/7/13, 8:17 PM, Rich Felker wrote:
>>>>> On Thu, Nov 07, 2013 at 06:57:15PM +0100, Andi Kleen wrote:
>>>>>>> Andi, it is unclear that if this is desired behaviour, one argument
>>>>>>> againist could be that if user wants to clone mutex type like
>>>>>>> int tp;
>>>>>>> pthread_mutexattr_gettype(a1, &tp);
>>>>>>> pthread_mutexattr_settype(a2, tp);
>>>>>>> should it preserve elision or not?
>>>>>> Yes it should.
>>>>> Sorry, it can't. The interface contact is set by POSIX, not something
>>>>> for glibc to design.
>>>> I'm confused. Is it OK for pthread_mutexattr_gettype() mask out the non
>>>> portable elision bits, PTHREAD_MUTEX_NO_ELISION_NP and
>>>> PTHREAD_MUTEX_ELISON_NP, set by pthread_mutexattr_settype()?
>>> Your question is misleading. As far as I understand,
>>> pthread_mutexattr_settype does not, from an application perspective,
>>> "set the elision bits of type". It sets the type, which might, due to
>>> the semantic requirements of the type, require forcing elision off, or
>>> allow a default of elision-on to be applied. As an implementation
>>> detail, this elision state is stored in the type field, but it is not
>>> part of the type. pthread_mutexattr_gettype must return the exact
>>> value that was passed to pthread_mutexattr_settype, nothing else.
>> OK, so then pthread_mutexattr_settype needs to be corrected not to set
>> PTHREAD_MUTEX_NO_ELISION_NP, correct?
> No. No, no, no. That's an implementation detail and not a problem at
> all. The problem is that pthread_mutexattr_gettype is returning the
> wrong value. It must return the same value that was passed to
> pthread_mutexattr_settype. This has nothing to do with where the
> elision flag bits are stored internally; it's purely a matter of the
> external interface.
> As the internal storage and logic for enabling/disabling elision was
> already a matter that was very HARD to solve when the elision patches
> were first proposed, I would be very skeptical of any solution to this
> bug that involves changing the internals. All that needs to be done is
> for pthread_mutexattr_gettype to mask the value it's returning so that
> it only contains the actual _type_ bits, not bits of the "type" field
> that were taken for storing additional non-type information.
So what is wrong with the patch that masks out
PTHREAD_MUTEX_NO_ELISION_NP? Should I also be masking out
PTHREAD_MUTEX_ELISON_NP as OndÅej suggested?