[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1406886931.4830.92.camel@eris.loria.fr>
Date: Fri, 01 Aug 2014 11:55:31 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: working C11 thread implementation
Hi everybody,
for anybody interested I attach a first working version, that is
mildly tested with a relatively big private application that I have
and that uses C11 threads quite intensively.
This implementation is still marked experimental, since it makes some
choices for which we don't know yet if they are final and which impact
binary compatibility.
We discussed several choices with Rich, and the result is a solution
that should only marginally affect existing code. This "marginally" is
- many pthread interfaces now are weak aliases to static functions
to avoid name space pollution of the C thread implementation. This
adds some noise to the symbol table of unstripped
executables. (but those where this is crucial do strip their
executables anyhow, don't they ?)
- pthread_create.o has two additional small wrapper functions that
augment its size by some byte
- pthread_create (now __pthread_create) has some instructions more
that do the selection between the POSIX and C calling conventions
the name space of pthread applications shouldn't be polluted.
This principal choice was guided by the idea to reuse maybe 90% or
more of existing code from pthreads, to minimize the risk of
introducing bugs and to ease maintenance.
The choices that affect the ABI that I mentioned are values of some
constants and the sizes of the types that are introduced. These may
change depending on glibc's choices and also according to future
developments.
For the choices of the constants, for this version they are such that
most wrapper calls result in being tail calls. I verified this by
looking into the assembler that is produced. As they are now, most of
these tail functions could also be just provided as weak aliases. We
chose to implement them as functions such that in case of change of
the constants we only have to recompile and no other maintenance is
required.
For the types, this just uses the pthread types for the moment,
nothing fancy. In the near future I will look into replacing some by
new implementations, to take advantage of the looser requirements for
C threads (no process shared control structures, no robust mutexes, no
cancelation).
The choices here will also depend on the restrictions that
POSIX will impose on compatibility between the two thread models, in
particular if some C thread functions will be considered cancelation
points for pthread.
The idea of all of this is that C threads should give way to a very
compact and comprehensive thread implementation. In this sense I think
for many users of musl this could be a valid alternative to
pthreads.
Also one should have in mind that C11 allows the use of its threads by
the library itself, as long as it follows the as-if rule. So a C
library could provide a parallel implementation of qsort or similar
compute intensive functions.
Jens
--
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
View attachment "thrd11.patch" of type "text/x-patch" (34802 bytes)
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
