On 3/31/2021 10:07 PM, George Neuner wrote:
> On Wed, 31 Mar 2021 16:31:12 -0700, Don Y
> <blocked...@foo.invalid> wrote:
>> I've been refactoring some of my RTOS documentation. Comments from
>> the reviewers suggest there's still some confusion as to terms
>> (despite the fact that I explicitly define them! :< )
>> All seem to understand the notion of a "thread".
> No old farts?
I don't think age -- or history -- is a primary source of the problem.
Concepts that I was taught 50 years ago have evolved. Or, been replaced.
I'm not tied to an initial understanding/explanation of a term or concept.
I think recent experience plays a far bigger role. And, for folks with
more narrow ranges of experience, that can often delude them into thinking
they have the One True Explanation.
I don't see anyone complaining about the use of task/process over
the use of "team"! (And, team suggests different connotations)
>> And, to a lesser extent, an "application" (this one's a bit
>> harder as there's often no clear-cut distinctions; do you
>> tie it to a "pre-packaged set of algorithms").
> Many (most?) people today realize that an "application" is an abstract
> concept that may involve multiple "programs" cooperating to achieve.
The problem with that is defining a "program" and defining a
"cooperating set of applications".
A single thread can be a complete program.
Alternatively, can be seen as an application (one wherein everything is
folded into the single executable)
A group of threads can be seen as implementing a (more complex!) program.
When does it become an "application"?
How do you differentiate between any one of the constituent applications
and the collection of them?
Is my speech synthesizer an application? (it can be free-standing!)
Are each of the threads within it "programs"? Or even applications?
(I can see an "application" that takes free-form text and normalizes
it to equivalent text, free of abbreviations, digits, special
symbols, etc. If a thread is performing these actions, is it JUST a
thread? A program? An application??)
What happens when I tie the synthesizer to the answering machine.
Is it still an application? Within an application?
I.e., where is the distinction between them (thread, program, application,
Or, do the terms have such ambiguous meanings that you may as well call
them Tom, Dick and Harry?
>> I had opted to use "task" instead of "process" to describe
>> resource containers. Too many folks with single-threaded
>> process experience brought that baggage to their understanding.
>> "Task" lets me avoid that.
> Few people today understand what is meant by "multi-programming" vs
> "multi-processing", or "concurrency" vs "parallelism", and fewer still
> know the historical meaning of "thread", let alone understand how it
> relates to "multi-threading".
> "Multi-tasking", as applied to computing, may refer to any combination
> of the "multi-" terms above. It is somewhat remarkable that it is so
> widely understood whilst simultanously being so utterly non-specific
> in meaning.
I see folks who've only worked in "single process space" environments
thinking every "executing entity" (what I would call a thread) is a
"task". This differs significantly with my definition; tasks aren't
>> Beyond that, I describe "jobs" -- collections of tasks to
>> implement a specific goal/service/etc. E.g., speech synthesis
>> is a *job* that uses several "tasks", each of which support
>> several (possibly concurrent) threads, to solve that particular
>> A job is smaller than an application, but bigger than a
>> single task (even though a task isn't an active entity).
> "Job" is more generic than "application" - however, in context, I
> would argue that they could (should?) be considered synonymous.
This quickly leads to the situation, above.
A collection of tasks (my definition) suggests certain dependencies
(on other tasks as well as resources, containers, etc.). This
being more than what task (process) or thread would imply.
Yet, the collection may not make sense as a free-standing entity;
it may not "do meaningful work".
>> Other legacy terms further add to the confusion: should
>> IPC be renamed ITC?
> Just retcon the acronym to be "inter-PROGRAM". Problem solved.
But two threads can be two "programs". The inherent aspect
of IPC is the fact that it crosses protection domains -- it
bridges *between* resource containers. That's not necessary
>> Are non-synchronous RPCs worthy of a different name? etc.
> No. If anybody bothers to look, they will discover that the literature
> recognizes both synchronous and asynchronous forms.
But the issue you (I) are trying to draw attention to is
the fact that the IPC is now across host boundaries.
I.e., it's a different level of IPC and has different
requirements and consequences.
>> Is there some more widely accepted taxonomy that can be
>> referenced? Or, just rely on explicit definitions (as
>> I've done) and not sweat the confusion that folks might
>> experience with legacy definitions?
> In the past you have - sometimes vehemently - opposed the use of
> conventional terminology on the grounds that it might imply something
> not true of your particular system.
This is exactly the case, here. There are only so many *meaningful*
terms that can be applied to general concepts. It would be silly to
call a "task" a "banana"! And, presumptuous to call it a "mission".
> I have argued that people are going to try to look up things they
> don't understand, and using unconventional terms hinders their
> learning. People who can't understand how conventional meanings apply
> (or not) to your system, then they are incapable of programming it.
That's why I've taken the time to define each term that I use.
The problem is one of coercing folks to abandon their preconceived
notions (which may be entirely accurate or appropriate FOR THEIR PAST
EXPERIENCES) and READING what is there before them.
I can always correct "misunderstandings", gently. But, there's
a limit to how available I will be for that, in the future.
So, the documentation has to clearly state my intent; yet do
so in a way that doesn't burden people with completely
>> [Alternatively, invent completely new bogo-terms just
>> to ensure my formal definitions are consulted?]
> May I suggest using random alphabetic sequences so there is no
> possibility of confusing your defined terms with actual words.
They'd have to be pronounceable; try reading your code to
someone when all of the symbols/identifiers are random
sequences of letters/symbols! :-/