This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Gsoc 2014 project proposal
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andrea Francesco Iuorio <andreafrancesco dot iuorio at gmail dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 26 Feb 2014 18:21:57 +0000
- Subject: Re: Gsoc 2014 project proposal
- Authentication-results: sourceware.org; auth=none
- References: <CAMaJsKjobBfmxjBRB2WP6MMLiAAD=QTV3bhO=hogeZHxmmotPg at mail dot gmail dot com>
On Wed, 26 Feb 2014, Andrea Francesco Iuorio wrote:
> There are also an extra feature that, even if not completely relevant
> to the C11 thread.h library, is quite usefull for thread programming
> in general: atomic variables. C11 provide a separate implementation
> and library for atomic variables ( stdatomic.h ). I decide to focus on
> the threads.h library for this project but, as you can see in my
> general schedule, i mantain some extra time because i don' t know at
> the moment if i' ll need or if it is mandatory having atomic variables
> for the thread.h implementation. If i don' t need it but i don' t have
> any other problems, i could use my extra time to implement
> stdatomic.h.
stdatomic.h is implemented in GCC 4.9; there is nothing to do in glibc
there.
If atomic operations are needed within your implementations of C11 threads
functions (rather than just within the pthread functions that your
implementations of C11 threads functions call) then it will be necessary
to use glibc's internal <atomic.h> facilities rather than relying on C11
atomic being available; glibc supports building with a range of GCC
versions.
> April - 18 May
>
> This period will be used to learn GNU codestyle conventions, the glibc
> structure, its pthread interface and for reading the C11 reference. I'
> ll also discuss with my mentor some project designs.
Also, learning about and working out a plan for namespace issues will be
important.
The idea is to implement C11 threads on top of pthreads - but the pthreads
functions are in the user's namespace in C11. That is, it's valid for a
C11 program to define its own pthread_* functions, and use them, and also
use the C11 threads functions. This means that implementations of the C11
threads functions can't use pthread_* functions under those names - they
need instead to use __pthread_* names. Many pthread_* functions are
already defined with such __pthread_* names (with pthread_* being weak
aliases for them), but if you need functions that aren't, they'll need to
be changed into weak aliases. Furthermore, this applies to anything used
indirectly by the functions you use. For example, pthread_create uses
mmap, but that's not a C11 function, so it will need to change to use
__mmap, so that a C11 function using thrd_create can also define its own
mmap function.
Namespace issues also apply to the header threads.h. I imagine you'll
want, for example, the C11 type mtx_t to have the same layout as the POSIX
pthread_mutex_t, so that C11 functions can be thin wrappers around the
POSIX ones, converting pointers to one type to pointers to the other. But
you can't just do "typedef pthread_mutex_t mtx_t;", because the name
pthread_mutex_t is in the user's namespace when <threads.h> is included
(C11 doesn't have the POSIX reservation of all *_t type names). So the
first step might be to split up <bits/pthreadtypes.h>, into one bit that
defines the type layout (not defining anything outside the implementation
namespace) and a separate bit that defines the pthread_*_t names (and
<threads.h> would only use the first of those bits, then define its own
names).
But you can't do "typedef __pthread_mutex_t pthread_mutex_t;" either,
because in C++ the first typedef name given to a struct or union without a
tag determines the name for mangling purposes, so is part of the ABI that
can't change. Thus you probably need to define the contents of the union
without a typedef for it, and then each header would declare a separate
union with those contents, using different typedefs, and pointer casts
would be used in the C11 threads implementation.
Both the above issues could to a large extent be addressed through
incremental cleanup patches - though to know what's useful, you need to
review the relevant parts of the C11 standard enough to identify the
pthreads functions and types you'll want to use in implementing C11
threads.
> 19 May - 22 June
>
> This period will be used for the basic implementation: thread data
> structures, thread handling and mutex basic managment.
>
> N.B. 23 June - Mid term evaluation. My primary goal is to have a basic
> and working function subset before the evaluation that, if possibile,
> could pass the patch review.
Note that when adding each function, you should also write testcases for
it for the glibc testsuite.
--
Joseph S. Myers
joseph@codesourcery.com