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

[Torvald Riegel]

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.