Re:Ten predictions (2004)
by seanmcdirmid on Friday February 15, 2013 @08:06PM
(#5229828)
If threads or processes or distributed computing is being used under the covers, does it still count as multi-threaded programming? I could go out and design an machine/OS that didn't use what we would think of threads (think Atari's Transputer [1]), and all these implicit threaded schemes would still work with my new construct. Now, we might not have transputers, but some of us get to use GPUs and such (still niche, but growing), where the unit of parallelism no longer resembles a thread very much.
My point was that multi-threaded programming hasn't taken off because it hasn't needed to. We just get some really smart experienced guys to write our infrastructure that encapsulates thread use and all of us get to reuse that.
Somebody still needs to be the smart experienced guy. Somebody still needs to write the language VMs, low level libraries and interfaces, device support etc etc.
I really don't get on with this mindset that someone else can fix it.
Another cool product is Disruptor - they have figured out a good, fast way to do message passing that minimizes the need for concurrent data structures between worker threads. (Provided of course you can model your app in that way). Under the hood, they have some crazy dep memory barrier based stuff, but for most of the programmers on a team, thinking about that stuff is just not needed. (as an aside, I think if Beautiful Code 2 was being written, I think Disruptor should be included, that source code is downright inspiring.)
The point being, once you have a good, trusted and vetted set of primitives, and are willing to put a little effort into working in a paradigm someone else sets, you get a lot of benefit. This is no different than using RoR or Django instead of rolling your own web framework.