This is the mail archive of the libc-alpha@sourceware.org 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: Specific Linux syscalls for glibc API


On Wed, Nov 18, 2015 at 05:43:02PM -0200, Adhemerval Zanella wrote:
> 
> 
> On 18-11-2015 17:23, Florian Weimer wrote:
> > On 11/18/2015 07:52 PM, Adhemerval Zanella wrote:
> >>
> >>
> >> On 18-11-2015 16:35, Florian Weimer wrote:
> >>> On 11/18/2015 06:58 PM, Adhemerval Zanella wrote:
> >>>
> >>>> Do we really have a compelling reason for gettid?
> >>>
> >>> It makes sense to use them in conjunction with process-shared futexes to
> >>> indicate ownership.  The return value of pthread_self isn't meaningful
> >>> to other processes.  Having to words (PID and address) complicates matters.
> >>
> >> Are you referring to PI-futexes?
> > 
> > No, a recursive lock implemented with a regular futex.
> > 
> > Florian
> 
> Right, but my question stands: for recursive mutex API where the idea is 
> to check if the thread already own the locks, is the best approach to
> expose gettid? Couldn't we encapsulate the recursive futex operation
> and make all the tid operation internally?

For glibc's own mutexes, this is already the case. I think Florian is
talking about situations where applications (for whatever reason) want
to use their own futexes directly. In this case you need a globally
unique identifier for the owner, and tid is the only plausible one.

Rich


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