This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gsoc 2014 project proposal

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 

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 

> 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 

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 

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 

> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]