Hi Dimiter, On 9/27/2014 7:22 AM, Dimiter_Popoff wrote:> On 27.9.2014 г. 08:04, upsidedown@downunder.com wrote: >> .... >> On modern virtual memory OSes (Linux/Windows) shared regions are >> implemented as .... > > Almost 20 years ago when I was laying the foundations of DPS I > did my definitions of these things as I saw them then, right or > not.I think it's hard to come to a consensus on many of these things. Too many different application domains at play, existing terminology, etc. One of the most productive things you can do in a project, early on, is to come to an agreement on a particular lexicon that you will use throughout the project and its descriptions/documentation. E.g., I have three different types of threads in my current system: - kernel threads, onto which one or more - user threads are multiplexed, each of which might support one or more - application threads. Each is a "thread" (using my previous definition of "thread") in its own context. But, the contexts for kernel threads and user threads (or application threads!) are hugely different -- as is the implementation/API! So, referring to different threads in different context levels is like comparing aardvarks to Buicks (performance, resources, guarantees, etc.) (system level documentation gains significance as complexity increases) How do you refer to a group of "processes" that work together to achieve some common goal? (in much the same way that a group of threads WITHIN a process can be considered as implementing that *process's* goal) And, how do you address components of a "solution" that exist on other processors -- possibly remote? (without a lexicon, you spend lots of verbiage trying to qualify the terms that you ARE using in a particular instance to accurately represent what you *intend* them to represent) "Can't tell the players without a program!" :>
Thread based software architecture vs Process based software architecture
Started by ●September 21, 2014
Reply by ●October 1, 20142014-10-01
Reply by ●October 2, 20142014-10-02
Hi Don, On Wed, 01 Oct 2014 11:54:24 -0700, Don Y <this@is.not.me.com> wrote:>E.g., I have three different types of threads in my current system: >- kernel threads, onto which one or more >- user threads are multiplexed, each of which might support one or more >- application threads. >Each is a "thread" (using my previous definition of "thread") in its >own context. But, the contexts for kernel threads and user threads >(or application threads!) are hugely different -- as is the >implementation/API!There are too many thread and thread-like nomenclatures: "user space" vs "green" vs "cthread" vs "activation". "Fiber" vs "coroutine". "OS" vs "kernel" [which, incidentally, may not be the same]. I'm sure I've forgotten someone's favorite term. Few people anymore know the distinctions between "multiprogramming", "multithreading" and "multiprocessing" ... and "multitasking" is used liberally to describe any combination of them.>So, referring to different threads in different context levels is like >comparing aardvarks to Buicks (performance, resources, guarantees, etc.) >(system level documentation gains significance as complexity increases)Given GM's problems, I'd rather drive an aardvark 8-(>How do you refer to a group of "processes" that work together to >achieve some common goal?A "gang", as in "gang scheduling" [even if scheduling doesn't apply]. George
Reply by ●October 2, 20142014-10-02
Hey George, [Watch your mail. I *think* I have finally got a "reliable" email machine... of course, having said that, *this* one will bite the dust like it's two predecessors! :< ] On 10/2/2014 3:47 AM, George Neuner wrote:> On Wed, 01 Oct 2014 11:54:24 -0700, Don Y <this@is.not.me.com> wrote: > >> E.g., I have three different types of threads in my current system: >> - kernel threads, onto which one or more >> - user threads are multiplexed, each of which might support one or more >> - application threads. >> Each is a "thread" (using my previous definition of "thread") in its >> own context. But, the contexts for kernel threads and user threads >> (or application threads!) are hugely different -- as is the >> implementation/API! > > There are too many thread and thread-like nomenclatures: "user space" > vs "green" vs "cthread" vs "activation". "Fiber" vs "coroutine". "OS" > vs "kernel" [which, incidentally, may not be the same]. I'm sure I've > forgotten someone's favorite term.Yup. But each of those tends to have connotations regarding implementation specifics (e.g., how scheduled). I have settled on referencing where in the "(machine) hierarchy" a thread executes to differentiate among them. And, separately describe their implementation(s). This lets me focus on the sort of environment in which to execute that each can expect. E.g., kernel threads have far stricter RT guarantees than application threads (which, currently, are effectively just multitasked). Also, the sort of skillset expected to develop in each of those environments.> Few people anymore know the distinctions between "multiprogramming", > "multithreading" and "multiprocessing" ... and "multitasking" is used > liberally to describe any combination of them.Shall we throw the RTOS/MTOS issue into the mix?? :> I guess that's why their are so many more "programmers" than "software engineers" :-/ And, microprocessor vs. microcomputer vs. microcontroller? (and we call this a *science*?? :< )>> So, referring to different threads in different context levels is like >> comparing aardvarks to Buicks (performance, resources, guarantees, etc.) >> (system level documentation gains significance as complexity increases) > > Given GM's problems, I'd rather drive an aardvark 8-(Poor ground clearance -- stubby legs!>> How do you refer to a group of "processes" that work together to >> achieve some common goal? > > A "gang", as in "gang scheduling" [even if scheduling doesn't apply].I prefer "job" though note there is a discrepancy in "parts of speech" vs. "thread" and "process". Perhaps because the term originated (in my past) to differentiate between "jobs" and "tasks"? OTOH, I try to avoid needing it by relying, instead, on "services" (and clients) as a more "natural" way of subdividing bigger "chores" (which also draws attention to the fact that a service may not be tied to a specific "job" but, rather, shared among many). C's off to hike -- take advantage of the cooler weather (finally!). I guess I get to play "chauffeur" :-/ --don