[RFC] Fixing pthread_* namespace issues for thrd_* symbols

Sorry for late reply.

My solution so far is this one, only for x86, will work on other
architectures as long as this strategy is acceptable. What I have
mainly done is copy pthread_mutex_t and pthread_cond_t renaming them,
so I won't be breaking any ABI and namespaces will be clean. Let me
know if it's acceptable.

Cheers.

--------------------------------------------------------------------------------------------------------------------------------------------

From 73f2aee3c1fc299c73607d23a49d75fefc72ad75 Mon Sep 17 00:00:00 2001
From: Juan Manuel Torres Palma <jmtorrespalma@gmail.com>
Date: Thu, 18 Jun 2015 09:48:19 +0200
Subject: [PATCH] New threads.h types

---
 nptl/Makefile                   |   3 +-
 sysdeps/x86/bits/threadstypes.h | 116 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 118 insertions(+), 1 deletion(-)
 create mode 100644 sysdeps/x86/bits/threadstypes.h

On Thu, 18 Jun 2015, Juan Manuel Torres Palma wrote:

> Sorry for late reply.
> 
> My solution so far is this one, only for x86, will work on other
> architectures as long as this strategy is acceptable. What I have
> mainly done is copy pthread_mutex_t and pthread_cond_t renaming them,
> so I won't be breaking any ABI and namespaces will be clean. Let me
> know if it's acceptable.

Contents shouldn't be duplicated, but you could e.g. have a shared header 
that defines macros such as __PTHREAD_COND_T_CONTENT, so cnd_t would be

typedef union
{
  __PTHREAD_COND_T_CONTENT
} cnd_t;

and pthread_cond_t similarly.

On Thu, 2015-06-18 at 14:12 +0000, Joseph Myers wrote:
> On Thu, 18 Jun 2015, Juan Manuel Torres Palma wrote:
> 
> > Sorry for late reply.
> > 
> > My solution so far is this one, only for x86, will work on other
> > architectures as long as this strategy is acceptable. What I have
> > mainly done is copy pthread_mutex_t and pthread_cond_t renaming them,
> > so I won't be breaking any ABI and namespaces will be clean. Let me
> > know if it's acceptable.
> 
> Contents shouldn't be duplicated, but you could e.g. have a shared header 
> that defines macros such as __PTHREAD_COND_T_CONTENT, so cnd_t would be
> 
> typedef union
> {
>   __PTHREAD_COND_T_CONTENT
> } cnd_t;
> 
> and pthread_cond_t similarly.
> 

I'm still not convinced that we should just create thrd_* data
structures that are the same size as pthread_*, especially for mutex.
I'm aware we have discussed this before, and using the same size might
be considered a safe bet -- however, we certainly don't need a robust
mutex list pointer for C11, nor do we know that a larger pthread_* type
would be sufficiently large for whatever we might want to do in the
future with the thrd_* types.

Also, just copying the algorithms isn't ideal in every case.  For
example, C11 mutex has different semantics than various POSIX mutex
types, which affects lock elision:
https://sourceware.org/glibc/wiki/LockElisionGuide
Also, we don't need to distinguish between mtx_plain and mtx_timed, nor
between recursive and non-recursive, I believe.

condvar semantics are the same IIRC.  We could make the cnd_t struct
smaller than current pthread_cond_t, but that is probably not as
relevant for performance as in the case of mutex, which could be
embedded with the data they are supposed to protect.

On Thu, Jun 18, 2015 at 06:20:48PM +0200, Torvald Riegel wrote:
> On Thu, 2015-06-18 at 14:12 +0000, Joseph Myers wrote:
> > On Thu, 18 Jun 2015, Juan Manuel Torres Palma wrote:
> > 
> > > Sorry for late reply.
> > > 
> > > My solution so far is this one, only for x86, will work on other
> > > architectures as long as this strategy is acceptable. What I have
> > > mainly done is copy pthread_mutex_t and pthread_cond_t renaming them,
> > > so I won't be breaking any ABI and namespaces will be clean. Let me
> > > know if it's acceptable.
> > 
> > Contents shouldn't be duplicated, but you could e.g. have a shared header 
> > that defines macros such as __PTHREAD_COND_T_CONTENT, so cnd_t would be
> > 
> > typedef union
> > {
> >   __PTHREAD_COND_T_CONTENT
> > } cnd_t;
> > 
> > and pthread_cond_t similarly.
> > 
> 
> I'm still not convinced that we should just create thrd_* data
> structures that are the same size as pthread_*, especially for mutex.
> I'm aware we have discussed this before, and using the same size might
> be considered a safe bet -- however, we certainly don't need a robust
> mutex list pointer for C11, nor do we know that a larger pthread_* type
> would be sufficiently large for whatever we might want to do in the
> future with the thrd_* types.

Actually you _do_ need robust list pointers if the committee decides
that the behavior is well-defined when a thread exits with a recursive
mutex held. The only way to implement this efficiently is to have a
linked list of all mutexes the thread holds so that they can be
changed to a permanently-locked state immune to tid reuse. I think the
possibility of needing to make this change, even if you think it would
be an unwanted change now, is a _major_ argument for keeping the
same-sized structures.

Rich

On Thu, 2015-06-18 at 13:53 -0400, Rich Felker wrote:
> On Thu, Jun 18, 2015 at 06:20:48PM +0200, Torvald Riegel wrote:
> > On Thu, 2015-06-18 at 14:12 +0000, Joseph Myers wrote:
> > > On Thu, 18 Jun 2015, Juan Manuel Torres Palma wrote:
> > > 
> > > > Sorry for late reply.
> > > > 
> > > > My solution so far is this one, only for x86, will work on other
> > > > architectures as long as this strategy is acceptable. What I have
> > > > mainly done is copy pthread_mutex_t and pthread_cond_t renaming them,
> > > > so I won't be breaking any ABI and namespaces will be clean. Let me
> > > > know if it's acceptable.
> > > 
> > > Contents shouldn't be duplicated, but you could e.g. have a shared header 
> > > that defines macros such as __PTHREAD_COND_T_CONTENT, so cnd_t would be
> > > 
> > > typedef union
> > > {
> > >   __PTHREAD_COND_T_CONTENT
> > > } cnd_t;
> > > 
> > > and pthread_cond_t similarly.
> > > 
> > 
> > I'm still not convinced that we should just create thrd_* data
> > structures that are the same size as pthread_*, especially for mutex.
> > I'm aware we have discussed this before, and using the same size might
> > be considered a safe bet -- however, we certainly don't need a robust
> > mutex list pointer for C11, nor do we know that a larger pthread_* type
> > would be sufficiently large for whatever we might want to do in the
> > future with the thrd_* types.
> 
> Actually you _do_ need robust list pointers if the committee decides
> that the behavior is well-defined when a thread exits with a recursive
> mutex held. The only way to implement this efficiently is to have a
> linked list of all mutexes the thread holds so that they can be
> changed to a permanently-locked state immune to tid reuse. I think the
> possibility of needing to make this change, even if you think it would
> be an unwanted change now, is a _major_ argument for keeping the
> same-sized structures.

But that's just accidental.  There may be other potential changes to the
standard that we're not aware of right now, so we don't really know
whether the same size would be sufficient, less would be sufficient, or
we'd actually need a bigger structure.

Maybe we should let the committee clarify that before giving ABI
stability guarantees for mtx_t.

On Thu, Jun 18, 2015 at 09:37:05PM +0200, Torvald Riegel wrote:
> On Thu, 2015-06-18 at 13:53 -0400, Rich Felker wrote:
> > On Thu, Jun 18, 2015 at 06:20:48PM +0200, Torvald Riegel wrote:
> > > On Thu, 2015-06-18 at 14:12 +0000, Joseph Myers wrote:
> > > > On Thu, 18 Jun 2015, Juan Manuel Torres Palma wrote:
> > > > 
> > > > > Sorry for late reply.
> > > > > 
> > > > > My solution so far is this one, only for x86, will work on other
> > > > > architectures as long as this strategy is acceptable. What I have
> > > > > mainly done is copy pthread_mutex_t and pthread_cond_t renaming them,
> > > > > so I won't be breaking any ABI and namespaces will be clean. Let me
> > > > > know if it's acceptable.
> > > > 
> > > > Contents shouldn't be duplicated, but you could e.g. have a shared header 
> > > > that defines macros such as __PTHREAD_COND_T_CONTENT, so cnd_t would be
> > > > 
> > > > typedef union
> > > > {
> > > >   __PTHREAD_COND_T_CONTENT
> > > > } cnd_t;
> > > > 
> > > > and pthread_cond_t similarly.
> > > > 
> > > 
> > > I'm still not convinced that we should just create thrd_* data
> > > structures that are the same size as pthread_*, especially for mutex.
> > > I'm aware we have discussed this before, and using the same size might
> > > be considered a safe bet -- however, we certainly don't need a robust
> > > mutex list pointer for C11, nor do we know that a larger pthread_* type
> > > would be sufficiently large for whatever we might want to do in the
> > > future with the thrd_* types.
> > 
> > Actually you _do_ need robust list pointers if the committee decides
> > that the behavior is well-defined when a thread exits with a recursive
> > mutex held. The only way to implement this efficiently is to have a
> > linked list of all mutexes the thread holds so that they can be
> > changed to a permanently-locked state immune to tid reuse. I think the
> > possibility of needing to make this change, even if you think it would
> > be an unwanted change now, is a _major_ argument for keeping the
> > same-sized structures.
> 
> But that's just accidental.  There may be other potential changes to the

That's your view; I'm not clear what the committee's will be. But as
is, requiring the tracking would not be a change to the standard; it
would be sticking with the requirements of the standard-as-written
rather than considering those requirements a defect (which they may
be, as you think they are) and changing the text so that they're no
longer required.

> standard that we're not aware of right now, so we don't really know
> whether the same size would be sufficient, less would be sufficient, or
> we'd actually need a bigger structure.
> 
> Maybe we should let the committee clarify that before giving ABI
> stability guarantees for mtx_t.

I would just go with the already-discussed type sizes rather than
leaving C11 threads support pending indefinitely waiting for the
committee's response, but I agree it would be good to go ahead and try
to push the issue forward as a request for interpretation. Any such
request should cite the Austin Group issue (which was ruled the other
direction) so it's clear that you're asking for a license for C11
recursive-mutex semantics to be more relaxed/lest-costly to implement
versus POSIX ones.

Rich