This is the mail archive of the
mailing list for the GCC project.
Re: [contribution] C11 threads implementation for Unix and Windows environments
- From: ltpmouse ltpmouse <ltpmouse at gmail dot com>
- To: Gkn Knc <gokan dot ekinci dot pro at gmail dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 20 Feb 2017 10:18:10 +0800
- Subject: Re: [contribution] C11 threads implementation for Unix and Windows environments
- Authentication-results: sourceware.org; auth=none
- References: <CADCmEBFFdMPr56TP+8ajvPSCmkHOB0rd94_as6H0F3o3+XUMrA@mail.gmail.com>
On 2017/2/20 6:59, Gkn Knc wrote:
> I am actually working on C11 threads implementation for Unix and
> Windows environments, and I would like to know if the GCC community
> could be interested.
The C library isn't part of gcc, so I am afraid this isn't the right
place for implementation of it. libc or mingw-w64 whatsoever seems more
GCC's threading support is based on another abstraction layer. See
comments in `gthr.h`.
> This is the github repository for my implementation :
A quick view of the source code discovers a few problems:
1. Please use reserved identifiers for implementation-specific macros
or entities, so you don't get compiler errors due to name conflict
with user-defined macros.
2. #include'ing windows.h in a header is almost always a bad idea.
If you want `HANDLE`, for example, use `void *`.
3. CC-BY-NC-ND is overstrict. Consider removing NC.
4. The prototype of C11 thread procedure [`int (void *)`] is
incompatible with that of pthread [`void *(void *)`] and WinAPI
[`unsigned long __stdcall (void *)`]. Casting a C11 one then passing
the result to `pthread_create()` or `CreateThread()` is certainly
5. On x86 Windows, the stack pointer of a thread created by
`CreateThread()` isn't aligned to a 16-byte boundary, but today
GCC assumes it is. This could result in segment faults once SSE is
enabled on x86. Please use `_beginthreadex()` instead.
6. The Windows mutex objects are quite heavyweight for in-process
synchronization. You probably need to write a user-space one
yourself or use the native CRITICAL_SECTION.
7. Condition variables are left unimplemented.
> I have implemented almost all the thrd_ and mtx_ functions (I need to
> do more tests), only those two following functions are not implemented
> yet : thrd_sleep and mtx_timed_lock (they are time related).
You haven't implemented condition variables and once initialization
either, which makes a thread library almost unusable.
> I would be glad to contribute. Best regards,