[HN Gopher] Ask HN: Why does the C K&R Book not talk about threads?
___________________________________________________________________
Ask HN: Why does the C K&R Book not talk about threads?
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?
Author : agomez314
Score : 12 points
Date : 2022-08-19 20:03 UTC (2 hours ago)
| retrac wrote:
| 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.
| GlenTheMachine wrote:
| 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 wrote:
| 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 ??
| andrewmcwatters wrote:
| 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 wrote:
| 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 wrote:
| "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_librari...
| mytailorisrich wrote:
| Threads are not a feature of the C language.
|
| In general, threads and their specific API are a feature of the
| OS.
| jsmith45 wrote:
| 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).
| sargstuff wrote:
| 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.
| IceMetalPunk wrote:
| 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 wrote:
| What is your first thought when you look at Hermann Rorschach's
| inkblots?
| Canada wrote:
| Are threads part of the C language or standard library?
| PaulHoule wrote:
| 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 wrote:
| 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
|
| 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 wrote:
| 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.
| eyberg wrote:
| 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.
| dpryden wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-19 23:02 UTC)