Forums

Task, process, thread, etc.

Started by Don Y March 31, 2021
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".

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").

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.

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
problem.

A job is smaller than an application, but bigger than a
single task (even though a task isn't an active entity).

Other legacy terms further add to the confusion:  should
IPC be renamed ITC?  Are non-synchronous RPCs worthy of
a different name?  etc.

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?

[Alternatively, invent completely new bogo-terms just
to ensure my formal definitions are consulted?]
On Wed, 31 Mar 2021 16:31:12 -0700, Don Y
<blockedofcourse@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? Historically "thread" referred to control flow (execution patterns) within a "program" (the code) and had nothing to do with concurrency or parallelism. The notion of "thread" as a scheduler entity dates from the early 60s, but this alternate meaning of "thread" really did not enter general use until the 90s. The notions of "continuation passing", "tail calling", etc., represent the last vestiges of the historical meaing of "thread". Outside of assembly programming - where e.g., "threaded interpeters" are known - the modern terminology does not actually include the word "thread".
>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.
>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.
>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 >problem. > >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.
>Other legacy terms further add to the confusion: should >IPC be renamed ITC?
Just retcon the acronym to be "inter-PROGRAM". Problem solved. 8-)
>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.
>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. 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.
>[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. YMMV, George
On Wed, 31 Mar 2021 16:31:12 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

> >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 >problem.
To me jobs smells like batch processing, The JOB card was the first card ahead of a deck of punched cards. The program was run to completion before the next JOB card was processed and executed.
On 01/04/21 07:49, upsidedown@downunder.com wrote:
> On Wed, 31 Mar 2021 16:31:12 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> >> 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 >> problem. > > To me jobs smells like batch processing, The JOB card was the first > card ahead of a deck of punched cards. The program was run to > completion before the next JOB card was processed and executed. >
Either that or one unit of work that is submitted externally and executed in an application by however many resources are necessary. Think of a "job shop"... https://marketbusinessnews.com/financial-glossary/job-shop/
On 3/31/2021 11:49 PM, upsidedown@downunder.com wrote:
> On Wed, 31 Mar 2021 16:31:12 -0700, Don Y > <blockedofcourse@foo.invalid> wrote: > >> 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 >> problem. > > To me jobs smells like batch processing, The JOB card was the first > card ahead of a deck of punched cards. The program was run to > completion before the next JOB card was processed and executed.
The problem with *every* term is that they all have preexisting definitions/expectations -- in ways that are unique to the particular environment in which they are encountered. Everyone brings their past experiences to new projects and, if the lexicon is vague (or, worse, if folks ASSUME they understand certain terms), then there's a mismatch between what is being conveyed and how that is being *interpreted*.
On 3/31/2021 10:07 PM, George Neuner wrote:
> On Wed, 31 Mar 2021 16:31:12 -0700, Don Y > <blockedofcourse@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, job, etc.)? 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 active!
>> 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 >> problem. >> >> 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. > 8-)
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 with threads-as-programs.
>> 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 foreign terms.
>> [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! :-/
On 01/04/21 12:03, Don Y wrote:
> On 3/31/2021 11:49 PM, upsidedown@downunder.com wrote: >> On Wed, 31 Mar 2021 16:31:12 -0700, Don Y >> <blockedofcourse@foo.invalid> wrote: >> >>> Beyond that, I describe "jobs" -- collections of tasks to >>> implement a specific goal/service/etc.&nbsp; E.g., speech synthesis >>> is a *job* that uses several "tasks", each of which support >>> several (possibly concurrent) threads, to solve that particular >>> problem. >> >> To me jobs smells like batch processing, The JOB card was the first >> card ahead of a deck of punched cards. The program was run to >> completion before the next JOB card was processed and executed. > > The problem with *every* term is that they all have preexisting > definitions/expectations -- in ways that are unique to the > particular environment in which they are encountered.
If you go much further down that path, you end up in Humpty Dumpty land. The "principle of least surprise" is a useful concept, coupled with - being explicit about what is meant - being explicit about what is not meant - examples of use
On 4/1/2021 5:02 AM, Tom Gardner wrote:
> On 01/04/21 12:03, Don Y wrote: >> On 3/31/2021 11:49 PM, upsidedown@downunder.com wrote: >>> On Wed, 31 Mar 2021 16:31:12 -0700, Don Y >>> <blockedofcourse@foo.invalid> wrote: >>> >>>> 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 >>>> problem. >>> >>> To me jobs smells like batch processing, The JOB card was the first >>> card ahead of a deck of punched cards. The program was run to >>> completion before the next JOB card was processed and executed. >> >> The problem with *every* term is that they all have preexisting >> definitions/expectations -- in ways that are unique to the >> particular environment in which they are encountered. > > If you go much further down that path, you end up > in Humpty Dumpty land. > > The "principle of least surprise" is a useful concept, > coupled with > - being explicit about what is meant > - being explicit about what is not meant > - examples of use
That's the point of formally defining each. THIS is a thread. See how it has state? See how it executes code? See what it implies is required to have MORE of them? THIS is a task. See how it CONTAINS threads? See how it warehouses resources (memory, objects, threads, etc.)? See how it doesn't (inherently) impose constraints on how many of each resource it can support? See how the task can't execute code -- but, rather, contains code? See how the threads don't contain/own resources (besides their state/stack)? Note how task A and task B do not overlap? See how an IPC (ITC?) is the means by which something in task A can communicate with something else in task B? See how these tasks -- containing these threads (and other resources) -- can implement a calculator? See how that calculator can have freestanding value as an "application" (sans user I/O)? See how that calculator can act as an expression resolver *in* the scripting language *application*? etc. See how this thread can convert "Dr. Smith lives at 123 Smith Dr." into "Doctor Smith lives at one hundred twenty three Smith Drive"? See how that likely doesn't have value as a freestanding application outside of its role *in* the speech synthesizer? See how these varied applications can act together (or separately) in this *system*? Resorting to novel terms just means everyone starts off in the same state of confusion. But, reusing "existing" terms -- many of which have been defined and redefined at different times and in different domains -- means some number of readers *will* be surprised. I don't see any way out -- other than documenting everything and providing hotlinks to each term's definition, regardless of the document in which it is encountered (I already draw attention to "special" terms with distinct formatting; I'd just have to add the additional links to a glossary, index and/or "defining document"). The downside is this almost forces the reader to read the documents electronically (it's too cumbersome to annotate each such reference with "See foobar on page 13 of Document blahdeeblah.")
On 4/1/2021 2:31, Don Y wrote:
> I've been refactoring some of my RTOS documentation.&nbsp; Comments from > the reviewers suggest there's still some confusion as to terms > (despite the fact that I explicitly define them!&nbsp; :< ) > > All seem to understand the notion of a "thread". > > 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"). > > I had opted to use "task" instead of "process" to describe > resource containers.&nbsp; Too many folks with single-threaded > process experience brought that baggage to their understanding. > "Task" lets me avoid that. > > Beyond that, I describe "jobs" -- collections of tasks to > implement a specific goal/service/etc.&nbsp; E.g., speech synthesis > is a *job* that uses several "tasks", each of which support > several (possibly concurrent) threads, to solve that particular > problem. > > A job is smaller than an application, but bigger than a > single task (even though a task isn't an active entity). > > Other legacy terms further add to the confusion:&nbsp; should > IPC be renamed ITC?&nbsp; Are non-synchronous RPCs worthy of > a different name?&nbsp; etc. > > Is there some more widely accepted taxonomy that can be > referenced?&nbsp; Or, just rely on explicit definitions (as > I've done) and not sweat the confusion that folks might > experience with legacy definitions? > > [Alternatively, invent completely new bogo-terms just > to ensure my formal definitions are consulted?]
Hi Don, I can only say what I have done with DPS - the "task" related wordings have not changed much if at all since the early 90-s. Back then I called a "task" what is a ...task, code running with its own stacks (user/system) and being put into use by the scheduler. Whether it runs on this or that core is irrelevant. And I took a decision to call a "process" a group of tasks having the same common data section (each task points to one). Obviously this is very different to what people would think of as a "process" on other systems where they call a process what I call a task, I think interchangeably. So I try to phase that term out by not using it. A thread is a dangerous term to use, to me it means a thread in a multi-threaded processor core. Which is much more hardware than software related, a virtual core can just run yet another task to another virtual core within the same physical one. Other than that I see no need for other names. Keeping it simple is nice, especially when it comes down to the basics like the ones I talk about here. There are more complex things to think and talk about of course, but these I leave to being various "objects" (dps has its inherent runtime system of objects) and to whatever "actions" you can "do" by/with these (I don't use the words "methods" and "apply", I just did not know these when I wrote the first implementation of the dps object system back around 1995, and my words seem to better describe what I have written anyway). Wait a second, you may be asking from an end user perspective. Well, my reply does not apply then... :-). I thought if people like the population of this group while I wrote it... Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Don Y <blockedofcourse@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". > > 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"). > > 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.
There are still a lot of folks who were introduced to basic OS concepts on MVS. And there "task" is what currently is called "thread". I dare to say that fraction of people who saw "multihtread task" is much lower than fraction of people who saw "multithreaded process". Anyway, IMO "Task" much stronger suggest single thread than process. -- Waldek Hebisch