[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ISO C 11 threads

From: Bruno Haible
Subject: ISO C 11 threads
Date: Thu, 20 Jun 2019 12:40:57 +0200
User-agent: 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 [1]
<threads.h>. This is a multithreading facility [2] 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 [3][4].)
  - 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,
  - illumos,
  - 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.

[1] https://en.wikipedia.org/wiki/C11_(C_standard_revision)
[2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

reply via email to

[Prev in Thread] Current Thread [Next in Thread]