Date: Mon, 04 Aug 2014 11:30:03 +0200 From: Jens Gustedt <jens.gustedt@...ia.fr> To: musl@...ts.openwall.com Subject: C threads, v3.0 Hi everybody, please find a new version for the C11 threads attached. This new version reimplements the functions for the control structures mtx_t and cond_t. (Only the functions, the types underneath didn't change for the moment.) This brings some interesting code simplification because - we don't have to care about process shared constructs - there are no attributes, so (almost) all code branches that concern optional features can be cut off - in particular there are no robust mutexes In any case, all of this should still have the same observable behavior as without C11 threads. All I intended to do so far is basically textual rewriting under the assumptions of C11. I'd like to discuss two issues before going further. The first is of minor concern. In many places of that code _m_lock uses a flag, namely 0x40000000. I only found places where this bit is read, but not where it is set. Did I overlook something or is this a leftover? The second issue concerns tsd. C threads can't be fine tuned with attributes, in particular they receive exactly as much stack space as we give them. They are supposed to implement an economic thread model that uses up as few resources as possible. In the current implementation tsd takes up a medium sized part of the stack (__pthread_tsd_size) if any of the application or linked libraries use pthread_key_create somewhere. My impression is that pthread_[gs]etspecific is already rarely used and that tss_[gs]et will be even less. C threads also introduce _Thread_local, a much more convenient interface as long as you don't have I don't think that this policy is ideal for C threads, but it could perhaps be revised for pthreads, too. My idea is the following. (version for C threads with minimal impact on pthreads) - don't assign a tsd in thrd_create - change pthread_getspecific, pthread_setspecific, tss_get, and __pthread_tsd_run_dtors such that they check for nullness of tsd. this is a trivial and non-expensive change. pthread_setspecific may return ENOMEM or EINVAL in such cases. The getters should just return 0. __pthread_tsd_run_dtors obviously would just do nothing, then. - change tss_set, to mmap the table if it is absent and if it is called with a non-null pointer argument. (I.e if it really has to store something). C11 allows this function to fail, so we could return thrd_error if mmap fails. - change thrd_exit to check for tsd and to unmap it at the end if necessary For thrd_create one of the consequences would be that main hasn't to be treated special with that respect. The additional mmap and unmap in tss_set should only concern entire pages. This should only have a minimal runtime overhead, but which only would occur for threads that call tss_set with a non-null pointer to be stored. Please let me know what you think. 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-v3.0.patch" of type "text/x-patch" (32207 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.