Sorry to be an pedant.
From your previous post
> The first thing to understand about threads is that processors do not support them.
Yes, but I would say by changing the emulator (augmenting the emulator software with your other software, sure) in the outside world, not doing something in the inside world, you have are implementing something closer akin to hardware concurrency support or processes.
> It doesn't map 1:1 to true multithreading (e.g., emulator save states represent the state of the entire machine including RAM, whereas thread contexts represent a much more minimal slice
Right, but I think if we're going to make a threads vs process distinction (vs concurrency in general) whether we have only a small opt-in set of communication channels / synchronization primitives (the mutex and barrier), or a wide open one (shared memory, be careful!) is the operative distinction.
Truly appreciate the thoughtful response.
First off: you're absolutely correct, and in ways which pain me to admit, because I do want to create correct analogies, as opposed to ones which mislead or half-inform.
I racked my brain, during the writing of this post, to figure out how to resolve these inconsistencies without sacrificing the goal of the post, which was basically to "unlock" an understanding of:
"The things you think are magic are actually just well-designed systems which you can, and should, reason about."
I think most programmers who use threads but don't know what they are have likely primarily had threads explained to them via analogies which teach their effects, not their nature. While this makes a lot of sense, and this instruction is certainly necessary and very valuable, it also has the unfortunate effect of mystifying and deifying such systems.
I also think most programmers would have no trouble accepting, or perhaps stating, that a thread is a data structure. But the nature of that data structure -- what goes inside it? -- has, in my experience, not been well understood.
And I truly think the core thing one has to do to demystify threads is explain what a thread holds -- a snapshot of CPU state -- because it links together the two most important things:
1. What would a thread structure even contain? 2. What features of a processor would even enable threads to function?
And with that as my primary motivation, I will defend the usefulness of this analogy. While the exact "state" being swapped is very different (which certainly demands explanation in any rigorous instruction), the fact that "it's simply state being swapped around, by code you can read, at an interval combined with conditions" is what I truly believe is the missing keystone -- and I do think this way of demonstrating it is useful to that degree.
But I am planning a part 3 which goes into fine detail on all of the disanalogies in part 2.
(Finally, I think my biggest sin of this whole thing is using the term "RTOS" in the title. That was stupid. This is not an RTOS at all. I didn't even use the term anywhere in the blog post itself, so why use it in the HN title? I regret this.)