[GSoC Project Proposal] ISO C11 threads.h implementation in GNU C Library

[Juan Manuel Torres Palma <j dot m dot torrespalma at gmail dot com>]

Hey guys this is my project proposal. This is an abstract version, if
anyone wants the full version, just ask for it, but I think this one is
long enough.

Thank you guys for taking time to read it.


Personal Info

Full Name: Juan Manuel Torres Palma.

Nickname: Lolo.

Country: Spain.

City: Granada.

University: Universidad de Granada.

Degree: BS in Computer Science

Timezone: CET (UTC/GMT + 1:00)

Spoken Languages:

Spanish: Mothertonge

English: B2-C1 CEF Level (Not accredited, TOEFL exam on may 12th)


Contact Info

E-Mail: j.m.torrespalma@gmail.com

Phone: +34 662 37 61 62

IRC: irc.freenode.net, #glibc channel, user jmtorrespalma


Project Proposal

I'm interested in the âISO C11 Threads implementation for GNU C
Libraryâ, offered by GNU.

In this project I will be adding the threads.h library support, defined
in a C standard revision (ISO/IEC 9899:2011), to the popular GNU C
Library. It's a feature needed because GNU C Library is widely used by
developers, and there are some of them that have been asking why it's
not available yet [1][2]. I plan to implement that new library using the
already tested and implemented POSIX thread (pthread), so the threads.h
will be on top of the pthread implementation.

The ISO C11 threads, with analyzability and bound-checking are the last
optional features from the ISO C11 standard that havent been implemented
in this library, so my goal is to add the âthreads.hâ API and become an
official maintainer of the library.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=14092

[2] http://stackoverflow.com/questions/8859394/c11-thread-h-in-gcc


Development methodology

I'm not used to work in big projects, so I will try, but I can't
guarantee that all work will be finished on time. That's why I will be
working function by function, don't skipping to the next until I have
completed and tested the current work. With this approach, I can
guarantee that at least, all work I've done is tested over and over, and
will be useful, and almost (hopefully) bug free. Personally, I prefer
quality over quantity. I think it's better if I do half the job pretty
good, instead of the whole library, but full of bugs, so anyone else
will have to read my code (we all know how horrible this task can be
sometimes), and fix it.

So my working methodology in a few words is: code, document, test,
repeat!


Related Skills

I have several experience working with threads programming as I have
coursed in college a few subjects related to this project. The skills
that i have obtained are a few hours of basic pthread, MPI and Java
threads. Last year I spend a whole semester using C and OpenMP.
Including theory of 3 different subject related to concurrent and
distributed programming, I think my skills are the appropriate to
acomplish this project goals.

Note: Any code can be provided under request, but I will need to ask my
teachers before, due to possible intellectual property issues.


Previous Open Source Work

The only project on a version 1.0 that I can show is my Simplified Solar
System app, in my GitHub repository:

https://github.com/jmtorrespalma/Simplified-Solar-System-app


Plan

I want to split this project in several parts or steps. I don't want to
think only in the coding part, cause obviously, a project of this size
must be solved planning very well what steps I will complete before, and
how I will focus my time and skills to achieve it. I think a good
strategy before starting is almost a win.

These are the steps I want to follow.

1 â Recopile information about glibc, pthread library, ISO C11 threads
and understand the size and time needed for this project.

2 â Study pthread API and ISO C11 specification, and any other
documentation available.

3 - Design a high level solution and show it to glibc maintainers, so I
can receive precious feedback to improve my solution and fix most issues
detected. (This plan is the high level solution that I'm thinking about)

4 â At this point, once my high level solution is accepted, I will
divide it in several small tasks that I want to accomplish while coding.
Thanks to that previous design, I think I will be able to approach the
implementation part pretty easier than just thinking directly on how the
code will be.

5 â Get used to glibc building, patching and testing suite. It may take
some time (a couple days) because it will be the first time working with
your methods.

6 â Start the coding!! I want to first create a complete header file of
threads.h, implement all types and some (being honest, just a couple of
them) basic and working functions (e.g. thrd_create, thrd_sleep,
thrd_exit), so it can all be tested. All documentation for implemented
functions must be up to date.

Here is where I plan (wish I could be) for mid-term evaluations. I think
it's a pretty ambitious goal, because I think the beginning of the
project is always the hardest, so if at this point I achieve this goal,
I will be in a very good position to finish the whole project.

7 â If I pass that midterm evaluation , I think the job will be easier,
because I will have one more month to totally focus on the project and
the remaining functions implementation.

8 â Once all the code, documentation and tests are done, I would like to
have one more week to review that everything is perfect and show the
maintainers community the whole work for an extensive review.

As I said before, this is a high level planning, once it's accepted I
will start thinking about some of the problems that can show up during
implementation, and how to fix them.


Scheduling

This is a general scheduling. It may be changed due to different nature
issues or suggestions

Note: From February to June I will still have classes to attend and
homework to do. So during that time I can guarantee around 20 hours of
work at week. Depends on how busy I'll be, but sometimes I will be able
to work more. After June I will be totally free, so I will can spend 40
or even more hours at week working in the project. That's one of the
reasons why I said the first part will be the toughest.

March â April 21st

During those two months I plan to accomplish steps 1 to 4 of my previous
plan. I want to be done with the design, even before knowing if I'm
getting the project or not, because if I get it, I can't afford to waste
some of my time of coding with design.

April 21st â June 23rd

I will spend this period of time with tasks 5 and 6, so I can try to
reach my mid-term goal.

June 23rd â August 11th

Hopefully I will spend that time working on task 7.

August 11th â August 18th

On the last week of the program, if possible, I would like to spend it
with step 8.

Every sunday I would like to discuss with my mentor what I should do,
and what shouldn't for the next sunday. I think weekly plannings are
really important.


What I can offer to this project

I have been a GNU/Linux user for 5 years now. During that time I have
learnt a lot about open source, free software, etc. The truth is that I
agree with most of those ideas, and that's why I'm pretty interested on
this kind of projects.

I'm also interested in systems software like top, bash, gcc, etc.

The GNU C Library is one of those critical tools needed to make a UNIX
like OS work and it's also free software and open source, so it
completelly fits in my fields on interests.

Another reason why I want to join the project, is because al the work
I'll do during this summer will be useful, and maybe will be running in
millions of devices that use glibc. I think this is great opportunity to
people like me to take my skills to a new next level, working with such
a great team of developers, and making totally useful code for the GNU
community.

In case I don't get the project, I won't give up. I'm really interested
in working in GNU C Library, so maybe I will try to join your developer
list, and do some easy tasks to learn more and more.

-- 
Juan Manuel "Lolo" Torres Palma.
Computer Science Student at Universidad de Granada.