6 ms·

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

20 points by agomez314 4y ago

I've been going over The C Programming Language book by K&R and noticed the glaring absence of threads in the book. Why is this?

IceMetalPunk 4y ago
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.
- StopTheWorld 4y ago
  What is your first thought when you look at Hermann Rorschach's inkblots?
PaulHoule 4y ago
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.
- sargstuff 4y ago
  Windows NT needed to use the threads concept developed else where to make things workable because of way the OS shared address space. https://en.wikipedia.org/wiki/Hybrid_kernel https://en.wikipedia.org/wiki/Hybrid_kernel Original linux/unix, same things could be done without the use of Windows NT style threads (aka fork/exec/pipe). Unix user space threads allow for a reduction in OS resource usage. Threads concept: Outside of mainframe in 60's, threads just extra stuff unix service (80's internet), 1 running program providing a service to multiple users 90's forward - service on an internet port allowing multiple user access to a service, where extra unused resources per user add up fast!
- ncmncm 4y ago
  More to the point, threads are an OS feature, not a language feature. Atomic types needed to implement things like mutexes to serialize access to shared state have become a language feature, lately. But K&R was written before that happened. The operations performed on those objects are Undefined Behavior as far as ISO Standards are concerned, but OSes have traditionally provided definitions, often by reference to Posix. So, a program using them is relying on definitions from both places, and usually several others besides.
  - slaymaker1907 4y ago
    Threads can also be a language feature which make them something of a leaky abstraction. For example, you can totally implement cooperative threading (aka virtual threads) through continuations and continuations can be implemented using only functions. You're also sort of wrong even with regards to C. While threading isn't really cross platform, threads also can't be implemented purely as a library, see the paper "Threads Cannot Be Implemented as Libraries". You need at least some support from the language in terms of controlling operation reordering. K&R certainly could have at least shown how to simulate concurrency in C. I wish I would have known about continuation passing/event loops when I implemented a dumbed down TCP on Arduinos.
    - sargstuff 4y ago
      Fork/exec & wait for "do your thing" notice is the pre-threads co-routine/continuation equivalent. Although, system("program to run") call allows better separation with less coding effort. Don't think concurrency in C would have been included per unix philosopy of program does one thing well. Would have been program to feed data to named pipe, program to read data from named pipe. Closest K&R C related example: Duff's Device & Simon Tatham's coroutines in C using macros. https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
      - sargstuff 4y ago
        Or protothreads example : http://dunkels.com/adam/pt/ http://dunkels.com/adam/pt/
eyberg 4y ago
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.
- Koshkin 4y ago
  > SMP It’s funny how more than a few programmers that I’ve talked to seemed to firmly associate threads (and processes) with the perceived need in multiple CPU cores to be able to run them. Preemptive multitasking on a single core simply did not look natural to them, to the point that some did not realize that it’s even possible. (One of them was also astonished to see, and to hear, a mechanical watch as he did not know such things existed.)
  - morelisp 4y ago
    If you only have one core threading remains an expensive abstraction both computationally and mentally. Without at least two cores there’s no reason to prefer threading to coroutines, select(2), state machine loops, etc.
    - lesserknowndan 4y ago
      Yes, but having threading is important if you can then run that code on a super computer to get the benefits - I’m talking about yesteryear when you’re own computer might have a single core Pentium II or something, but you could then run it on an SGI or other with a lot of parallelism.
dpryden 4y ago
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.
retrac 4y ago
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.
mytailorisrich 4y ago
Threads are not a feature of the C language. In general, threads and their specific API are a feature of the OS.
- jsmith45 4y ago
  Threads have been a C language feature for over a decade now, starting with C11. (although C11's threads had arguable posix comatibility issues until fixed in c17).
  - 1over137 4y ago
    Yeah, but the latest edition of the K&R C book was 1988, predating C11 by a lot.
sargstuff 4y ago
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.
GlenTheMachine 4y ago
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.
- sargstuff 4y ago
  User level threads concept also doesn't really work with limited resources available for 60's/70's/80's machines. Especially when charged by the precise amount of time/space/resources used, ?? 60's/70's mainfram vs. pc at home vs. today's cloud computing ??
- 95014_refugee 4y ago
  The Multimax was NS16k/NS32k-based. After the Gould acquisition they switched to the 88K, but never (AFAIK) built anything on the 68K family. Kind of a pity, really; nice hardware, but terrible luck with processor families.
  - GlenTheMachine 4y ago
    You are correct. I dug out my Multimax manual, and my version says it came with dual processor cards populated with NS32032 CPUs operating at 12.5 MHz.
Canada 4y ago
Are threads part of the C language or standard library?
andrewmcwatters 4y ago
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.
- sargstuff 4y ago
  K&R is C language specific .dll, .dylib, .so are files created by/used by the linker the compiler calls to create/use the OS specific .dll, .dylib, .so files. .dll is Microsoft Windows library .so is unix related static library. .dylib is MacOS related library.
  - sargstuff 4y ago
    "The Standard C Library" by P.J. Plauger. would be a match for stuff discussed in K&R. Although, K&R is pre-C 89 standard, Plauger is more along the lines of C-89/92 standard. More recent "standard ansi C library" : https://en.wikibooks.org/wiki/C_Programming/Standard_libraries https://en.wikibooks.org/wiki/C_Programming/Standard_librari...
    - sargstuff 4y ago
      "Expert C Programming, Deep C Secrets" by Peter van der Linden can help with filling in the C 89/92 related miscellaneous stuff aka libraries, linkers/compilers, header files, make files, etc.
deanmen 4y ago
Because there are no threads in 1977 UNIX, and threads are not a part of C99 (but they are in C11).
cmollis 4y ago
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.
- AbundantSalmon 4y ago
  Must be a legacy name, as they still have it as a unit at a Uni I've been to: https://handbook.curtin.edu.au/units/unit-ug-unix-and-c-programming--comp1000v1 https://handbook.curtin.edu.au/units/unit-ug-unix-and-c-prog...
  - mlambie 4y ago

20 points by agomez314 4y ago

I've been going over The C Programming Language book by K&R and noticed the glaring absence of threads in the book. Why is this?

IceMetalPunk 4y ago

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.

StopTheWorld 4y ago
What is your first thought when you look at Hermann Rorschach's inkblots?

PaulHoule 4y ago

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.

sargstuff 4y ago
Windows NT needed to use the threads concept developed else where to make things workable because of way the OS shared address space. https://en.wikipedia.org/wiki/Hybrid_kernel https://en.wikipedia.org/wiki/Hybrid_kernel Original linux/unix, same things could be done without the use of Windows NT style threads (aka fork/exec/pipe). Unix user space threads allow for a reduction in OS resource usage. Threads concept: Outside of mainframe in 60's, threads just extra stuff unix service (80's internet), 1 running program providing a service to multiple users 90's forward - service on an internet port allowing multiple user access to a service, where extra unused resources per user add up fast!
ncmncm 4y ago
More to the point, threads are an OS feature, not a language feature. Atomic types needed to implement things like mutexes to serialize access to shared state have become a language feature, lately. But K&R was written before that happened. The operations performed on those objects are Undefined Behavior as far as ISO Standards are concerned, but OSes have traditionally provided definitions, often by reference to Posix. So, a program using them is relying on definitions from both places, and usually several others besides.
- slaymaker1907 4y ago
  Threads can also be a language feature which make them something of a leaky abstraction. For example, you can totally implement cooperative threading (aka virtual threads) through continuations and continuations can be implemented using only functions. You're also sort of wrong even with regards to C. While threading isn't really cross platform, threads also can't be implemented purely as a library, see the paper "Threads Cannot Be Implemented as Libraries". You need at least some support from the language in terms of controlling operation reordering. K&R certainly could have at least shown how to simulate concurrency in C. I wish I would have known about continuation passing/event loops when I implemented a dumbed down TCP on Arduinos.
  - sargstuff 4y ago
    Fork/exec & wait for "do your thing" notice is the pre-threads co-routine/continuation equivalent. Although, system("program to run") call allows better separation with less coding effort. Don't think concurrency in C would have been included per unix philosopy of program does one thing well. Would have been program to feed data to named pipe, program to read data from named pipe. Closest K&R C related example: Duff's Device & Simon Tatham's coroutines in C using macros. https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
    - sargstuff 4y ago
      Or protothreads example : http://dunkels.com/adam/pt/ http://dunkels.com/adam/pt/

eyberg 4y ago

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.

Koshkin 4y ago
> SMP It’s funny how more than a few programmers that I’ve talked to seemed to firmly associate threads (and processes) with the perceived need in multiple CPU cores to be able to run them. Preemptive multitasking on a single core simply did not look natural to them, to the point that some did not realize that it’s even possible. (One of them was also astonished to see, and to hear, a mechanical watch as he did not know such things existed.)
- morelisp 4y ago
  If you only have one core threading remains an expensive abstraction both computationally and mentally. Without at least two cores there’s no reason to prefer threading to coroutines, select(2), state machine loops, etc.
  - lesserknowndan 4y ago
    Yes, but having threading is important if you can then run that code on a super computer to get the benefits - I’m talking about yesteryear when you’re own computer might have a single core Pentium II or something, but you could then run it on an SGI or other with a lot of parallelism.

dpryden 4y ago

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.

retrac 4y ago

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.

mytailorisrich 4y ago

Threads are not a feature of the C language. In general, threads and their specific API are a feature of the OS.

jsmith45 4y ago
Threads have been a C language feature for over a decade now, starting with C11. (although C11's threads had arguable posix comatibility issues until fixed in c17).
- 1over137 4y ago
  Yeah, but the latest edition of the K&R C book was 1988, predating C11 by a lot.

sargstuff 4y ago

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.

GlenTheMachine 4y ago

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.

sargstuff 4y ago
User level threads concept also doesn't really work with limited resources available for 60's/70's/80's machines. Especially when charged by the precise amount of time/space/resources used, ?? 60's/70's mainfram vs. pc at home vs. today's cloud computing ??
95014_refugee 4y ago
The Multimax was NS16k/NS32k-based. After the Gould acquisition they switched to the 88K, but never (AFAIK) built anything on the 68K family. Kind of a pity, really; nice hardware, but terrible luck with processor families.
- GlenTheMachine 4y ago
  You are correct. I dug out my Multimax manual, and my version says it came with dual processor cards populated with NS32032 CPUs operating at 12.5 MHz.

Canada 4y ago

Are threads part of the C language or standard library?

andrewmcwatters 4y ago

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.

sargstuff 4y ago
K&R is C language specific .dll, .dylib, .so are files created by/used by the linker the compiler calls to create/use the OS specific .dll, .dylib, .so files. .dll is Microsoft Windows library .so is unix related static library. .dylib is MacOS related library.
- sargstuff 4y ago
  "The Standard C Library" by P.J. Plauger. would be a match for stuff discussed in K&R. Although, K&R is pre-C 89 standard, Plauger is more along the lines of C-89/92 standard. More recent "standard ansi C library" : https://en.wikibooks.org/wiki/C_Programming/Standard_libraries https://en.wikibooks.org/wiki/C_Programming/Standard_librari...
  - sargstuff 4y ago
    "Expert C Programming, Deep C Secrets" by Peter van der Linden can help with filling in the C 89/92 related miscellaneous stuff aka libraries, linkers/compilers, header files, make files, etc.

deanmen 4y ago

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

cmollis 4y ago

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.

AbundantSalmon 4y ago
Must be a legacy name, as they still have it as a unit at a Uni I've been to: https://handbook.curtin.edu.au/units/unit-ug-unix-and-c-programming--comp1000v1 https://handbook.curtin.edu.au/units/unit-ug-unix-and-c-prog...
- mlambie 4y ago