[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ISO C 11 threads
ISO C 11 threads
Thu, 20 Jun 2019 12:40:57 +0200
KMail/5.1.3 (Linux/4.4.0-145-generic; KDE/5.18.0; x86_64; ; )
We are now 8 years past ISO C 11, and still few systems have the ISO C 11 
<threads.h>. This is a multithreading facility  that very much resembles
POSIX threading. The differences are:
- Different header file: <threads.h> instead of <pthread.h>.
- Different types: thrd_t instead of pthread_t etc.
- Different function names (thrd_*, mtx_*, call_once, cnd_*, tss_*) instead
- No "advanced" features, just the basic functionality.
- Mutexes work only in a single process, not across fork()ed processes.
- No equivalent of 'pthread_sigmask'.
- It adds a 'thread_local' storage class, that corresponds to GCC's
- The exit value of a thread is an 'int' instead of a 'void *'. (I think
this is meant to ease portability to Windows .)
- Locks/mutexes: There are only plain and recursive locks, no read-write
locks and no spin locks. The type of a lock (plain vs. recursive and
whether it supports waiting with a timeout) has to be specified when the
lock is created. I think this is a recognition of the fact that the
implementation of a recursive lock or a lock that supports waiting is
more complex than a the implementation of a plain lock.
So far this facility is implemented in
- glibc >= 2.29,
- FreeBSD >= 10,
- Solaris >= 11.4 (with a bug in thrd_join),
- AIX >= 7.1 (with terrible bugs in thrd_create and thrd_join).
To make it portably usable, I'm adding support for this facility to gnulib,
for all systems with POSIX or Windows threads.
No support for older systems, namely Minix 3.1.8, HP-UX 11.11, IRIX 5.3,
Solaris 2.4, BeOS.
Gnulib can only provide the types and functions. The 'thread_local' storage
class is something that requires compiler and linker support; we cannot
provide this portably. Applications have to use the tss_* functions instead
(just like with GCC, you need pthread_get/setspecific when '__thread' is not
On native Windows, this implementation uses native Windows threads, not the
mingw pthreads emulation. This is unlike the gnulib-invented 'thread', 'lock',
'cond', 'tls' modules, which by a historical accident (the way threadlib.m4
was written) use mingw pthreads when available and not disabled through
gl_AVOID_WINPTHREAD or --enable-threads=windows.