This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][BZ #15790] Have pthread_mutexattr_gettype mask out the elision bit.

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]