3

I'm just now getting into threading and specifically I want to learn POSIX threads, and everything about them. As implemented in Linux. I'm looking for resources to learn about them but many of those resources are very old. Some of them date back to

I am not asking for resources. Being that these two books are so old, I'm wondering how on topic they'd be. How is the POSIX API versioned? On Wikipedia all I see is this,

POSIX Threads is an API defined by the standard POSIX.1c, Threads extensions (IEEE Std 1003.1c-1995).

I'm not sure if that means that there are no updates since 1995 to the threading parts of POSIX or not? Is there any way to judge the relevancy of the material?

Evan Carroll
  • 78,363
  • 46
  • 261
  • 468

1 Answers1

7

At the very bottom of the Wikipedia page you reference in the "External Links" section, you will find a link to the current Posix specification of pthreads.h, which includes a history of changes. There have been a few, but the basic principles are intact. So the books you mention are probably still good learning materials. (I still have a well-thumbed copy of Programming with POSIX Threads on my bookshelf.)

As is mentioned in the comments below, C11 provides atomics and thread-local storage, which is implemented by GCC since 4.9. (Thread-local storage was previously available in GCC as an extension, so it is not that new.) The existence of thread-local storage reduces the need for the Pthreads thread-local storage interfaces, but that is a small part of the Pthreads library (and, although thread-local storage is easier to use and syntactically more convenient, it doesn't really change program structure much.)

C11 also specifies an optional threads.h header which contains threading function similar to Pthreads. However, glibc does not include this header, and the use of Pthreads is still pretty well universal, although both open- and closed-source threads.h implementation do exist. (For open source implementations, see the musl library and/or the FreeBSD implementation, available since 10.0.) Conceptually, the C11 interfaces are very similar to Pthreads; obviously, they have different names and in some cases they are simplified. However, once you've mastered Pthreads, you should have little trouble understanding any C11-threads programs you come across.

rici
  • 234,347
  • 28
  • 237
  • 341
  • I would also recommend looking at the Conforming to -sections in the relevant [Linux man pages project](http://man7.org/linux/man-pages/) man pages for each function. There is one major change that all POSIXy systems now support: the [`__thread`](https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html) keyword, standardized in C11's `` as `thread_local`. It makes `pthread_key_create()`, `pthread_key_destroy()`, `pthread_setspecific()`, and `pthread_getspecific()` unnecessary. – Nominal Animal Jul 13 '18 at 07:08
  • 1
    @NominalAnimal, in replaces most of them, yes. But there are still use cases for `pthread_key_...` or its equivalent C11 `tss_...`, namely when you need to install a destructor for a thread local variable. – Jens Gustedt Jul 13 '18 at 07:26
  • @JensGustedt: True, although you can achieve the same with `__thread` using cleanup/atfork functions. (I personally prefer to use thread cleanup functions (`pthread_cleanup..()`, `pthread_atfork()`), rather than data item destructor functions. I've always found the data destructor functions a poor fit to a procedural programming paradigm; something lifted out from OOP to help OOP-oriented developers.) – Nominal Animal Jul 13 '18 at 07:34
  • @NominalAnimal, right in POSIX you have these. For the simpler C11 thread model (where `thread_local` comes from) you don't have these interfaces. – Jens Gustedt Jul 13 '18 at 10:34
  • 1
    @JensGustedt: Actually, `__thread` came about from GNU/Linux, and very quickly spread to all POSIXy systems -- it's not that old. (You do know all that, I believe. Just pointing it out for others.) From there, it was adopted to C++, and from there to C11. To be honest, I think most of C11 is utter garbage; the standard no longer helps developers, and is instead a rubberstamp for vendors. As I've pointed out many times already, a standard which includes an annex full of single-vendor "safe" I/O functions, but does not standardize `getline()`, is not a sane standard. – Nominal Animal Jul 13 '18 at 11:21