"12 years ago everyone was wondering how we'd program on multicore CPUs" is either laughable or enlightening to read as an OS developer.
Thankfully many DAWs, video editing, CAD, servers and other useful software saw the value in multi-core workloads.
It’s a thing… just not for web folks most of the time.
But go back 20 years, and you predate Linux RCU. The OS Developers weren't laughing at the problem then.
Arguably the Linux Real Time patches are solving a similar problem, which could be said to be extracting maximum parallelism out of the code. For Real Time this isn't so they can run in parallel, but rather so a higher priority task can interrupt a lower priority one with impunity. Real Time Linux still isn't done yet, although it's getting close.
I believe it was the DEC Ultrix dev team who, reportedly, amused themselves after hours by making transparencies of Linux source code, projecting them on a screen, cracking open a few beers and having a laugh at the idiot mistakes those college kids made -- mistakes, of course, that you can avoid by choosing a real Unix OS.
It took a while for Linux to actually be taken seriously outside of home-lab tinkering.
It took a while and big companies like IBM and organizations like the OSDL and FSG (which became the Linux Foundation) pouring many thousands of person hours and millions of dollars into it. The Linux kernel has plenty of independent "amateur" (not paid to do so) contributors but it's also got a lot of paid contributors for who it's their day job.
It's an awesome mix of contributors but I think there's a definite generational shift around the 2.2/2.4 to a much more capable kernel than 2.0 and before. Had Linux not gotten the financial backing it did I don't know that it would be where it is today.
Typical audio software, for example, has been multithreaded since the 90s (simply because the audio callback and the GUI must run in different threads). And in the mid 2000s these threads started to run on different CPUs.
- a way to avoid blocking the UI,
- tool to gain some perf. on new fancy multi-core processors,
- making the code much harder to read and debug, which often makes them a victim in a cost-benefit analysis.
There were in fact attempts for new concurrency paradigms (like Software Transactional Memory) which however led nowhere outside academia.
So what are some other ways of handling multi-core code that you were taught?