3 ms·

Threads can also be a language feature which make them something of a leaky abstraction. For example, you can totally implement cooperative threading (aka virtu

by 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?
  - ncmncm 4y ago
    Not all machines reorder instructions, and not all machines have more than one core. You always need control over your compiler, but that often does not suffice. With more than one core, you cannot do without one of atomics or custom assembly code sequences. And if the CPU reorders instructions all by itself, you need special instructions besides. Atomics in the language mean you get to let the compiler worry about most things. But an atomic operation may take enormously longer than you hope. An atomic increment may take a hundred times as long as an ordinary increment.

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?
- ncmncm 4y ago
  Not all machines reorder instructions, and not all machines have more than one core. You always need control over your compiler, but that often does not suffice. With more than one core, you cannot do without one of atomics or custom assembly code sequences. And if the CPU reorders instructions all by itself, you need special instructions besides. Atomics in the language mean you get to let the compiler worry about most things. But an atomic operation may take enormously longer than you hope. An atomic increment may take a hundred times as long as an ordinary increment.