Re: Pending issues for next release

[Rich Felker <dalias@aerifal.cx>]

On Tue, Apr 02, 2013 at 09:40:47PM +0200, Jens Gustedt wrote:
> > > Having scanned through the musl sources, I don't think that supporting
> > > C11 threads would be a big deal. Some additional wrappers should
> > > suffice, I think.
> > 
> > The main difficulty is respecting the namespace. Some functions would
> > need to be renamed to be in the reserved namespace with aliases for
> > their POSIX names.
> 
> I we just talk of the 'thrd_' functions, first, I think that just
> aliases wouldn't do the trick. They have different calling conventions
> and interpretation of the return values (thrd_yield e.g), so a
> decision would have to be made where to split things. My first idea
> would be to have the shared code in static functions and have a
> wrapper for each interface specification.

I didn't mean to make the C11 functions aliases for the POSIX
functions. I meant the POSIX functions would be renamed to have names
like __pthread_mutex_lock, with pthread_mutex_lock as a weak alias,
and mtx_lock calling __pthread_mutex_lock.

> > The ABI isn't defined yet.
> > There's clearly a choice to be made between making the C11 objects
> > lighter, since they don't have to provide as much functionality, and
> > making them just duplicates of the POSIX objects (so that code can be
> > shared for both), and it's not clear which is better.
> 
> I was thinking that it would clearly be preferable to re-use the POSIX
> types for the control structures (mtx_t and cnd_t) as much as
> possible. If it'd just be for the fact that that code is already well
> tested. But as you pose the challenge, you are right that there could
> be advantages in re-implementing parts.
> 
> In particular a mtx_t being just an int and using futexes directly on
> top has certainly some charm. But if you'd want to support
> mtx_recursive things might get more complicated.

Single int is not enough for an efficient implementation; you need a
second one as a waiter-count, and a third one as a reference count if
you want to do recursive locks. This is still somewhat smaller than
the pthread_mutex_t we have now (6 ints on 32-bit systems and
considerably larger on 64-bit ones if I remember right). The size
doesn't matter so much when you're locking code, but if you're locking
data, the size of the mutex inside the structure it's protecting can
be a big deal if you have lots of them.

> > Even if the objects are shared, we may choose not to share code if it
> > allows the C11 synchronization primitives to have better performance
> > than the POSIX ones.
> 
> performance figures that clearly distinguish two such implementations
> would probably be quite difficult to obtain.
> 
> Both implementations for control structures should basically do some
> instructions and one or two atomics for the fast path. For the slow
> path, this then would mainly be calls to futex. So the atomics should
> dominate the fast path, futex the slow path.

The issue is that for POSIX mutexes, the fast path is much longer due
to having to support lots of mutex types and having different
conditional paths for all them. I've optimized it as much as possible
for regular mutexes, but I think the runtime in the uncontended case
is still about 50% longer than the ideal regular-mutex-only
implementation.

> For thread creation we could even have the effect that C11 is
> slower. C11 can't be created detached, so any thread creation for
> "detached" threads has first to create a thread state somewhere that
> then would be freed when detaching.

I don't follow...

> In any case we should then (shared objects, different primitives) come
> up with a linker scheme that inhibits a successful linking of an
> application that tries to use POSIX an C11 interfaces simultaneously.

Why would you want use of both to fail? The next issue of POSIX will
almost surely be aligned with C11, in which case, I would expect it to
include all the C11 thread interfaces, at least optionally, and
certainly not to forbid their use in programs that use the POSIX
thread interfaces. Even if not, I see no reason why using one set of
interfaces should preclude using the other. It's certainly reasonable
for a program to use one library written in pure C using C11 threads,
and another library written to POSIX using POSIX threads.

Rich