That's pretty neat.
The metaphor I usually go for when it comes to for threads is having several widgets that need to be assembled. To begin working on Widget B, you have to pause the work on Widget A. Adding SMP is like adding a second person to help assemble widgets, but you're still using the same toolbox, so if you both need the same screwdriver, there's no performance benefit to having a second person. Multicore is having multiple workbenches each with their own toolbox so they can operate completely in parallel.
A mutex is like having a specialized tool that can only be used by one widget assembly at a time. Like, each workbench might have a full set of screwdrivers, hammers, wrenches, sockets, etc., but you only have 1 welder.
A semaphore is a tool that can be used by a limited number of widgets, like an oven that can fit up to 4 widgets.
I think this is a pretty damn good metaphor for the introduction of these concepts, especially in a context where the learner(s) might need to imminently apply this knowledge.
What drove me to write this post (as someone who didn't attend college where I might've learned exactly what I'm about to say -- big grain of salt) is that it took me being forced by circumstance to become a firmware engineer for a time to actually understand not just how to multithread well, but what the hell this all even was.
And I guess I saw one too many Reddit comments (mistake #1) which downplayed the idea that there's any benefit to knowing the answer to such things.
That all said, this blog post / metaphor is definitely aimed at someone who's already been using threads effectively for some time -- I don't think it'd fare very well as a first introduction.
> Adding SMP is like adding a second person to help assemble widgets, but you're still using the same toolbox, so if you both need the same screwdriver, there's no performance benefit to having a second person.
This sounds like hyperthreading – or, maybe I'm missing the screwdriver in the metaphor :)
Hyperthreading is Intel's implementation of SMP
I think you mean SMT (simultaneous multithreading), as opposed to SMP (symmetric multiprocessing)?
Ah hell, that was MY mistake. It should be SMT in my original comment and it's way too late to edit it now.
Funny thing is, when I was first typing that comment, I started with "Hyperthreading" and deleted it in favor of SMP to be vendor agnostic.
EDIT: And it should have been SMT anyways!
As a special challenge: explain (Software) Transactional Memory, as eg implemented in Haskell, in your metaphor.
STM is pretty similar to how some databases implement transactions.
[dead]
SMP is a second processor, even more redundant than a second core. Its own cache, memory, Northbridge access, etc.
Yeah, I messed up SMT vs SMP. Can't edit it now, though.
Ah well -- the article itself has its own fair share of accuracy issues -- and I learned something from your conversation, which wouldn't have happened without said mistake.