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.