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
appropriate.

GCC's threading support is based on another abstraction layer. See
comments in `gthr.h`.

> This is the github repository for my implementation :
> https://github.com/eau-de-la-seine/c-standard-threads
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
    undefined behavior.
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,
Good luck.


-- 
Best regards,
ltpmouse

Reply via email to