Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.sys.amiga.misc Subject: Multitasking definitions (Was: True Multitasking) Message-ID: Date: 23 Jan 91 19:37:26 GMT References: <1991Jan18.055614.13889@zorch.SF-Bay.ORG> <42149@nigel.ee.udel.edu> <672@tnc.UUCP> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 53 In-Reply-To: m0154@tnc.UUCP's message of 22 Jan 91 17:11:10 GMT In article <672@tnc.UUCP> m0154@tnc.UUCP (GUY GARNETT) writes: This is my understanding of the "threads" or "lightweight processes" issue; feel free to correct me if I am not up to date on the terminology. "threads", or "lightweight processes" are separate execution traces which share the address spaces with one or more other processes, regardless of the other processes weight. They were designed to allow many of the simpler multitasking jobs (like re-drawing the screen or recalculating the spreadsheet) to be done with lower overhead. They are implemented in OS/2 and perhaps the Mach kernal. The definition is right. The reason for creation (at least in the Unix world) is wrong. There, they were built because Unix didn't have a way off sharing data between distinct proceses (code has been shared between processes running the same program for quite a while now). "coroutines" are the individual processes in a cooperatinve multitasking environment. That's not the definition as I learned it. Coroutines are a programming technic, wherein each coroutine calls the others as subroutines. Instead of going to that subroutine and returning, it goes to that subroutine, which eventually calls another coroutine. The next time a coroutine is invoked after calling a corouinte, it sees that coroutine returning. Unlike cooperative multitasking, all coroutine calls are known at link time. Also, each coroutine specifies which task starts next; this isn't left up to a scheduler somewhere. As I understand it, the Amiga does not have "threads" or "lightweight processes". It depends on how you define the phrase :-). If you define it as a task with low-context-switch overhead between another task, then all Amiga tasks are lightweight. Although all of the tasks and processes on the Amiga share an address space, it is not intended that there be multiple execution traces through the same code and data (with the well-defined exception of certian operating system code). You *CAN* do it, but you do not get the same benefits that threads get - the operating system overhead is the same, and writing code to work this way adds its own overhead. There is a CBM-supported way of creating such tasks. This looks a lot like thread creation on OSF. In fact, doing a Posix-compliant threads library for AmigaDOS shouldn't be to hard.