cox@stpstn.UUCP (Brad Cox) (01/21/91)
In article <1991Jan16.005818.3521@rodan.acs.syr.edu> wwtaroli@rodan.acs.syr.edu (Bill Taroli) writes: >In article <kkirksey.910112013111@lab12.eng.auburn.edu> kkirksey@eng.auburn.edu (Kenneth B. Kirksey) writes: >>Can somebody please tell me why Apple has yet to implement TRUE multitasking >>in the system software? I know that it's really not that hard of a task, >>especially since the amiga has had it for quite some time. Is there a valid >>reason for not doing it? I'm really curious > >I think you've used just about one of the most vague terms in the comuting >world. The software swamp is full of such vague terms. IMHO, this stems from a semi-religious belief, or dogma, that there is a single, best meaning for any term; i.e. a panacea meaning that applies to everything, at every level of granularity. Mature domains, like hardware engineering, don't get into these hassles, which in my opinion, is only a sign of software's immaturity. Just as hardware engineers package some stuff as office equipment (rack-level integration), other stuff as cards (card-level integration), other stuff as chips, and others as silicon blocks and gates, isn't the same likely to work for us? My Nov90 IEEE software article, Planning the Software Industrial Revolution, proposes that we bypass this immature confusion by adopting the hardware engineering vocabulary, and particularly its impatience with those who seek single, 'true', panacea solutions: Rack-level integration: as in Unix heavyweight processes; preemptive Card-level integration: lightweight coroutines; non-preemptive Chip-level integration: loosely coupled objects as in Smalltalk/Objective-C Block-level integration: tightly-coupled objects packaged as subroutines Chip-level integration: tightly-coupled objects; expressions, variables, etc -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
minich@d.cs.okstate.edu (Robert Minich) (01/22/91)
by cox@stpstn.UUCP (Brad Cox): |>I think you've used just about one of the most vague terms in the comuting |>world. | | The software swamp is full of such vague terms. IMHO, this stems from a | semi-religious belief, or dogma, that there is a single, best meaning | for any term; i.e. a panacea meaning that applies to everything, at every | level of granularity. | | Mature domains, like hardware engineering, don't get into these hassles, | which in my opinion, is only a sign of software's immaturity. | My Nov90 IEEE software article, Planning the Software Industrial Revolution, | proposes that we bypass this immature confusion by adopting the hardware | engineering vocabulary, and particularly its impatience with those who | seek single, 'true', panacea solutions: | | Rack-level integration: as in Unix heavyweight processes; preemptive | Card-level integration: lightweight coroutines; non-preemptive | Chip-level integration: loosely coupled objects as in Smalltalk/Objective-C | Block-level integration: tightly-coupled objects packaged as subroutines | Chip-level integration: tightly-coupled objects; expressions, variables, etc How would applying some precise terms from hardware terminology, whose mapping to software entities is at best strained, lead to less confusion? I don't see the need for a NEW vocabulary when the existing one can work just fine. The use of "true" to describe software entities can be likened to using "true integration" to (mis)describe any of the above hardware entities. How about if we just use "preemptive multitasking" to describe itself and let "multitasking" refer to any number of schemes where two or more otherwise unrelated threads of execution are active at one time? We can use "multithreaded application" to describe a single program that has multiple threads of execution. Here are the definitions I propose: preemptive multitasking -- this shouldn't need to be explained! multiprogramming -- multiple tasks executing with one thread per task (typical time sharing) mulithreading -- more than one thread of execution in a single application True <anything> (tm) -- a term used by those who don't know how to communicate -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| "I'm not discouraging others from using |=(___)= | minich@d.cs.okstate.edu | their power of the pen, but mine will | U | - "Ackphtth" | continue to do the crossword." M. Ho
jxf@orion.cis.ksu.edu (Jerry Frain) (01/22/91)
In article <1991Jan22.035748.275@d.cs.okstate.edu> minich@d.cs.okstate.edu (Robert Minich) writes: >How about if we just use "preemptive multitasking" to >describe itself and let "multitasking" refer to any number of schemes where >two or more otherwise unrelated threads of execution are active at one >time? We can use "multithreaded application" to describe a single >program that has multiple threads of execution. I would agree with this argument, except for one thing. The term "multitasking," I believe, is derived from the feature of Ada to allow the programmer to establish separate threads of control. The Ada term for a thread is a "task." Thus, I believe, the term multitasking was coined from the multiple-tasking feature of Ada. This use of "multitasking" is synonymous to Mr. Minich's definition of "multithreading" (as it should be). >Here are the definitions >I propose: > multiprogramming -- multiple tasks executing with one > thread per task (typical time sharing) Correct. "Multiprogramming"is defined as a system which has the ability to have more than one program (job) in main storage, and have the processor switch rapidly between the programs so that they appear to be executing concurrently. "Time-sharing" is multiprogramming except that now interactive services are provided to users who have on-line terminals while larger jobs execute in the background. I defined "multitasking" (informally) above, so I won't repeat myself. "Preemptive multitasking" does not _really_ make sense. "Preemptive" certainly does not describe "multitasking." We already know that the Mac is time-sharing. To say that it is also multitasking adds a new dimension which is not accurate, especially if you believe the part about the origin of the term "multitasking" stems from the Ada language. The words "preemptive" and "cooperative" describe the way in which jobs in a multiprogramming/time-sharing environment relinquish the processor so that another job may be scheduled for execution. In this context, "preemptive" and "cooperative" describe one characteristic of the scheduling policy used by the operating system. That is, a "preemptive scheduler" typically suspends a job (process) after a "time quantum" has expired, and a "cooperative" scheduler waits until the currently-running job relinquishes the processor *on its own*. Thus, the Macintosh implements a cooperative _scheduler_. Unix, AmigaOS, et. al. perform preemptive _scheduling_. > True <anything> (tm) -- a term used by those who don't know > how to communicate Depending upon its use, of course. In this case, I would tend to agree. Regards, --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf
gsm@gsm001.uucp (Geoffrey S. Mendelson) (01/23/91)
jxf@orion.cis.ksu.edu (Jerry Frain) Wrote: > >I would agree with this argument, except for one thing. The term >"multitasking," I believe, is derived from the feature of Ada to >allow the programmer to establish separate threads of control. The first use, I know of, of the words "task" and "multitasking" applied to the IBM OS/360 circa 1966. Program execution was controlled by a Task Control Block (TCB). You could either LINK (expecting to return) or XCTL (transfer control, no return) to another task and it would run under your TCB. If you ATTACHed a task, a separate TCB was created and viola' you were multitasking. By the way, if anyone cares, it was pre-emptive multitasking. In those day the operating system designers were concered with sharing an expensive resource (the computer) among many cheap users (people). Now the computers are cheap and the people are expensive. Mendelson's first law of micro-computers: "Micro computer designers consider it their GOD given right to make the same mistakes mainframe designers did twenty years ago." :-) N.b. I think I should change it to thirty years. :-) -- ---------------------------------------------------------------------------- | Geoffrey S. Mendelson | Computer Software Consulting | Dr. | | (215) 242-8712 | IBM Mainframes, Unix, PCs, Macs | Who | | uunet!gsm001!gsm | | Fan too!|
raphael@research.canon.oz.au (Andrew Raphael) (01/24/91)
In article <1991Jan22.082018.14641@maverick.ksu.ksu.edu> jxf@orion.cis.ksu.edu (Jerry Frain) writes: >In article <1991Jan22.035748.275@d.cs.okstate.edu> minich@d.cs.okstate.edu (Robert Minich) writes: >>How about if we just use "preemptive multitasking" to >>describe itself and let "multitasking" refer to any number of schemes where >>two or more otherwise unrelated threads of execution are active at one >>time? We can use "multithreaded application" to describe a single >>program that has multiple threads of execution. >We already know that the Mac is time-sharing. To say that it is also >multitasking adds a new dimension which is not accurate, especially if >you believe the part about the origin of the term "multitasking" stems >from the Ada language. Indeed. It isn't the Mac which is multithread, it's the programming language environment. For example, I use a Macintosh Forth compiler (Mach 2) which is multithreaded, and works under Multifinder. Thus I write applications which are multithread, and run on a multiprogramming OS. >Thus, the Macintosh implements a cooperative _scheduler_. Unix, AmigaOS, >et. al. perform preemptive _scheduling_. The Forth I mention uses a co-operative scheduler for the multithreading. -- Andrew Raphael <raphael@research.canon.oz.au> Golden lads and girls all must, as chimney sweepers, come to dust.
davoli@natinst.com (Russell Davoli) (01/26/91)
In article <1991Jan22.082018.14641@maverick.ksu.ksu.edu>, jxf@orion.cis.ksu.edu (Jerry Frain) writes: > > I would agree with this argument, except for one thing. The term > "multitasking," I believe, is derived from the feature of Ada to > allow the programmer to establish separate threads of control. > > The Ada term for a thread is a "task." Thus, I believe, the term > multitasking was coined from the multiple-tasking feature of Ada. > This use of "multitasking" is synonymous to Mr. Minich's definition > of "multithreading" (as it should be). > I don't know about this. I've been out of school about a year and half, and in the OS course I took the last semester, the prof never mentioned Ada in relation to the term "multitasking". Like a number of other posters recently, I'd be really surprised if the origin of the term can be attributed to Ada, esp. since Ada is relative newcomer on the scene (isn't the language only 6 or so years old). I'm inclined to believe that Ada took the term and narrowed the definition to apply to a language construct. Don't get me wrong, I'm just as tired of these terminology arguments as everybody else is and couldn't be happier if we'd just agree on something. I think you're definitions are good ones, but we're still stuck with all the popular definition now that popular computing magazines are talking about this, in article like "Why you need Windows multitasking" or some such like. (I picked on Windows because it's new, but I'm sure I've seen articles of this ilk about MultiFinder when it showed up.) Anyway, this wasn't intended as a flame, and I'm sorry if you feel singed. I just felt putting my $.02 worth in. Russell Davoli National Instruments Corp. C C popular defi
drd@siia.mv.com (David Dick) (01/30/91)
In <1991Jan22.082018.14641@maverick.ksu.ksu.edu> jxf@orion.cis.ksu.edu (Jerry Frain) writes: >In article <1991Jan22.035748.275@d.cs.okstate.edu> minich@d.cs.okstate.edu (Robert Minich) writes: >>How about if we just use "preemptive multitasking" to >>describe itself and let "multitasking" refer to any number of schemes where >>two or more otherwise unrelated threads of execution are active at one >>time? We can use "multithreaded application" to describe a single >>program that has multiple threads of execution. >I would agree with this argument, except for one thing. The term >"multitasking," I believe, is derived from the feature of Ada to >allow the programmer to establish separate threads of control. The term "multitasking" probably antedates Ada by at least a decade. David Dick Software Innovations, Inc. [the Software Moving Company (sm)]