Cross-platform libraries that implement the C standard interface for threading.
When the C standard incorporated threading in C11, the model was based on pthreads. The 'p' in "pthreads" stands for "POSIX", which means that the model very closely resembles what was already incorporated into POSIX-based systems. The PosixCThreads library is really just a very thin wrapper around the ptherads library. This is true even in gcc, which requires that pthreads be linked to an executable making use of C threads in gcc 8.0 and beyond.
The Windows model was not designed with pthreads in mind. While Windows supports the same concepts in general, the specifics of the Windows implementations of those mechanisms are very different. For the most part, this can be dealt with by defining types and functions that abstract the details of the internals of Windows mechanisms away from the user of this library.
There is, however, one very fundamental difference that can't easily be abstracted by types: Thread-specific storage. In Windows, thread-specific storage is intended to be achieved by "Thread Local Storage" slots which (a) don't align well to the POSIX/C threads model and (b) don't have any mechanism for the destructors defined by POSIX/C threads. Because of this, I needed a way to keep track of thread-specific storage that would meet the requirements of the standard. I use a red black tree in my WinCThreads.c library to achieve that. In my testing, it seems that the red black tree lookup mechanism that I use may be suboptimal relative to whatever the implementation is in pthreads, however the difference is not significant enough to warrant me trying to optimize the library further for my needs.
The way to use this library is to include "CThreads.h" and compile in the appropriate library for your system. You can actually include both source files in your build process if you're lazy like I am and just include all the files in the directory. The source files are wrapped in ifdefs that detect the compiler.
Initially, my thought for the CThreads.h include was that it should include the ISO C threads.h file if it was available on the system and turn off all library wrappers. Unfortunately, this caused more problems than it solved for me. Visual Studio now officially supports C17, but not threads.h, which goofed me up. There is also a problem on Linux that making use of the the ISO C definitions in gcc 8 and beyond greatly increases the version level dependency of GLIBC. This made it practically impossible for me to compile my code on one system and use the same binary elsewhere. I finally gave up trying and just always use my own wrappers now. The linker will link to the local version of the function names over the versions in GLIBC, so all I have to ensure is that the system I'm moving my binary to supports pthreads.
Doing all this provides me with a cross-platform way of having thread support that will hopefully be obsoleted by future compiler support for the C standard threading model. Maybe one day... :-) I hope that others find it useful too.