5 ms·

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

by 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/
  - yesenadam 4y ago
    That page was a super-fascinating read, thank you!
- ncmncm 4y ago
  If you don't have language support for atomic operations, you need to rely on assembly language library functions provided by the OS; or code your own. Those in turn rely on hardware features provided by the CPU manufacturer and usually bound to special machine instructions. On simple-enough machines, it suffices to control when interrupts are enabled. More complicated machines with multiple out-of-order cores and fancy cache systems are enormously more fiddly.
  - jstimpfle 4y ago
    A lot of concurrency can be implemented without atomics. Maybe in fact all? I'm not super deep in the theory. But I don't think you can go far without controlling instruction reordering done by the compiler (as well as the CPU), which is what GP was talking about.
    - sargstuff 4y ago
      Thread and/or concurrency abstraction (and/or other abstractions provided by a language) allows information/knowledge about how to deal with the abstraction (option or default) to be provided to the compile behind the scenes. aka when coding a program, when was the last time coded a stack/heap to do a function call with parameters instead of using a language provided way of calling a function with parameters? This just seems weird with C because C language was designed to map as closely to hardware instructions as possible (hence why quite a lot of things in C are 'undefined' / dependent on platform used.) Most modern languages are designed so that hardware issues are not a programmer's thing, but a compiler implementor's thing. Allows for much more sophisticated hardware without burdening the non-systems programmer.
      - jstimpfle 4y ago
        Note that C is modern enough so all the thread stuff that you don't want to do yourself _can_ be done by a library, if you prefer. Why? Because the language already supports all the necessary primitives, like control over memory ordering. I don't necessarily think that more is required in a language. Why would you want in a language what can be easily provided by a library?

by ncmncm 4y ago

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/
- yesenadam 4y ago
  That page was a super-fascinating read, thank you!
ncmncm 4y ago
If you don't have language support for atomic operations, you need to rely on assembly language library functions provided by the OS; or code your own. Those in turn rely on hardware features provided by the CPU manufacturer and usually bound to special machine instructions. On simple-enough machines, it suffices to control when interrupts are enabled. More complicated machines with multiple out-of-order cores and fancy cache systems are enormously more fiddly.
- jstimpfle 4y ago
  A lot of concurrency can be implemented without atomics. Maybe in fact all? I'm not super deep in the theory. But I don't think you can go far without controlling instruction reordering done by the compiler (as well as the CPU), which is what GP was talking about.
  - sargstuff 4y ago
    Thread and/or concurrency abstraction (and/or other abstractions provided by a language) allows information/knowledge about how to deal with the abstraction (option or default) to be provided to the compile behind the scenes. aka when coding a program, when was the last time coded a stack/heap to do a function call with parameters instead of using a language provided way of calling a function with parameters? This just seems weird with C because C language was designed to map as closely to hardware instructions as possible (hence why quite a lot of things in C are 'undefined' / dependent on platform used.) Most modern languages are designed so that hardware issues are not a programmer's thing, but a compiler implementor's thing. Allows for much more sophisticated hardware without burdening the non-systems programmer.
    - jstimpfle 4y ago
      Note that C is modern enough so all the thread stuff that you don't want to do yourself _can_ be done by a library, if you prefer. Why? Because the language already supports all the necessary primitives, like control over memory ordering. I don't necessarily think that more is required in a language. Why would you want in a language what can be easily provided by a library?