Add C11 threads.h implementation in addition to pthread implementation for multithreaded encoding. #822
Conversation
…n for multithreaded encoding. The switching between both APIs is done via macros as this seemed simple enough. There are only slight differences between pthread and C11 threads, in particular the way attributes are handled for mutex and condition variable (both not used by FLAC), the signature of the thread function, the return value of trylock, and the error handling, where pthread uses errno and C11 threads use an explicit return value enum. The wrapper macros are prefixed with FLAC__ as is common in FLAC code. All functions are renamed to closely resemble the C11 names instead of the POSIX names, as this is the more forward-looking approach. The macro to enable C11 threads is HAVE_C11THREADS. When both HAVE_C11THREADS and HAVE_PTHREAD are defined, the C11 implementation is preferred. This does not add any build system support for C11 threads, so the current default behaviour remains unchanged.
|
This whole thing is useful because MSVC provides native C11 threads support in recent versions, and has (of course) no pthread support. See https://devblogs.microsoft.com/cppblog/c11-threads-in-visual-studio-2022-version-17-8-preview-2/. Also see https://stackoverflow.com/questions/24557728/does-any-c-library-implement-c11-threads-for-gnu-linux for some (outdated) discussion about C11 threads adoption in C standard library implementations. |
|
@sezero As you mentioned the extra pthread dependency in #634 (comment), this might be relevant for you. I did choose C11 threads instead of native WinAPI threads because the impedance mismatch between C11 threads and pthread is really low implementation-wise. As far as I know, MinGW-w64 does not support C11 threads yet, so this is not of immediate use with that particular toolchain. I would expect MinGW-w64 to eventually support C11 threads (it's part of ISO C after all), so this might be useful in the future. For now, it adds in particular multithreading support with MSVC, for which the extra pthread dependency was even more of a hassle than it is for MinGW-w64. |
…be disabled via a new hidden setting [Export]FLACMultithreading=true. This depends on <xiph/flac#822>, and is a no-op until our libflac supports multi-threading. [Imp] FLAC Samples: Add hidden setting [Sample Editor]FLACMultithreading=false. As samples are short for the most part, thread creation overhead might dominate the encoding, so this is disabled by default. This has not been benchmarked. This depends on <xiph/flac#822>, and is a no-op until our libflac supports multi-threading. [Imp] openmpt123: Enable FLAC multithreading unconditionally. git-svn-id: https://source.openmpt.org/svn/openmpt/trunk/OpenMPT@23042 56274372-70c3-4bfc-bfc3-4c3a0b034d27
Sorry, really not interested |
The switching between both APIs is done via macros as this seemed simple enough. There are only slight differences between pthread and C11 threads, in particular the way attributes are handled for mutex and condition variable (both not used by FLAC), the signature of the thread function, the return value of trylock, and the error handling, where pthread uses errno and C11 threads use an explicit return value enum. The wrapper macros are prefixed with FLAC__ as is common in FLAC code. All functions are renamed to closely resemble the C11 names instead of the POSIX names, as this is the more forward-looking approach.
The macro to enable C11 threads is HAVE_C11THREADS. When both HAVE_C11THREADS and HAVE_PTHREAD are defined, the C11 implementation is preferred.
This does not add any build system support for C11 threads, so the current default behaviour remains unchanged.