[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1407144603.8274.248.camel@eris.loria.fr>
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.
