Why does the C K&R Book not talk about threads?

In 1987, I was a student intern at NASA Langley in a group that researched parallel computing. They had a dialect of C called Concurrent C that ran on a very specialized platform, the Encore Multimax, which IIRC had 16 Motorola 68000 CPUs. The language had special constructs for threading, synchronization, and message passing, which had to be supported by specialized bus protocols in hardware.

The point being, when K&R was written, threading was highly experimental, and it remained so for at least the next decade.

Because they didn’t exist at the time that book was written. I took a Unix/c class as a comp sci elective (yes, you read that right). However this was 1988 so no Linux. We worked mostly on pc’s which was pretty progressive for the time and mainframes. We had a small mini computer (can’t remember from who.. dec? That doesn’t sound right..). Anyway, forked processes, no threads. In fact, I didn’t know what a thread was until the windows nt announcement in the early 90s. The irony is evident.

Threads were not a mainstream thing back in the day. Even though 360 mainframes had threads in 1967, the original Unix didn’t have threads. Threads were important in Windows NT from the very beginning but Linux didn’t get them until 1996.

This was first published in 1978.

We didn't have commoditized SMP machines until late 90s, early 2000s. Similarly, we didn't have 'good' threads until the early 2000s. In fact if you were coding in the 90s and early 00s you would've heard that threads were "bad", which was true at the time. Unfortunately, today you can still find this reiterated on places such as stack overflow even though it has long been untrue. We also deal with the fact that a lot of software made in the 90s has never been upgraded or replaced to deal with the architectural considerations of those days versus now. Today you can get up to 416 vCPUs on Google Cloud.

Threads are not a feature of the C language.

In general, threads and their specific API are a feature of the OS.

C language equivalent in late 70's would have been user defined array of functions (flyweight threads); use of fork()/exec() system call. (vs. current threads abstraction library/api)

Closest thing to direct "in-language thread concept" would be proposed C language definition addtion in which source code could specify a case statment block(s) be assigned to run on different cpu core(s) than the running program.

The K&R book is primarily focused on Unix and similar operating systems, and they didn't have threads when the book was written.

The first edition of K&R was published in 1978.

Wikipedia says that OS/360 had a notion of threads as early as 1967, although the distinction between threads and processes wasn't as clearly defined at that time.

In 1978, threading and concurrency was still an area of academic research. There are some great papers from Dijkstra and Lamport from that era, but much of the research at that time considered each concurrent "thread" to be a separate program; that is, each process was conceptually single-threaded, and if you wanted to do multiple things you made multiple processes for them.

The idea of multiple mini-processes inside a single process came later and took a while to stabilize into its modern form. POSIX didn't standardize thread-related APIs until 1995 and Linux didn't get modern POSIX threads support until Linux 2.6 in 2003.

POSIX threads date to the mid-1990s or so. Traditional C and UNIX simply did not have the concept of lightweight in-process threads, as used today. Any threading library would have been implementation-specific. In UNIX, if you needed another thread of execution, you started up another process.

Threads were certainly known of when C and UNIX were designed, but they weren't that common for typical programming tasks. Real-time tasks, mostly, where you need to respond to something while busy. Networks and GUIs were a big push behind threading becoming standard in most languages and environments in some way. But if you have no network sockets or other sources of events, and no need to render graphical output simultaneously with processing, you probably don't need threads. That's the kind of computing environment the K&R Book was written for.

It also doesn't seem to talk about libraries, which leads me to ask myself where the authoritative source is for reading about .dll, .dylib, and .so files. GCC and Clang documentation are about as close as you can get. To be fair, these are OS-specific details, but Unix-likes do have this, and the book talks about Unix system interfaces.

Mac OS X Archived documentation talks about it, presumably Microsoft documentation does as well, but AFAIK there is no official Linux documentation for it outside of compiler documentation.

Because there are no threads in 1977 UNIX, and threads are not a part of C99 (but they are in C11).

Are threads part of the C language or standard library?

I can't answer your question, but I do want to say that when I read "K&R", my first thought was "Kidnapping & Ransom", and I was very confused and spent 30 seconds trying to figure out what the C stood for before finally clicking through... This is where my mental state currently exists, I guess.