Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!husc6!think!ames!ucbcad!ucbvax!cbosgd!cblpf!cbstr1!Karl.Kleinpaste From: Karl.Kleinpaste@cbstr1.att.com Newsgroups: comp.unix.wizards Subject: Re: light weight processes and threads Message-ID: <302@cbstr1.att.com> Date: Wed, 15-Jul-87 22:35:50 EDT Article-I.D.: cbstr1.302 Posted: Wed Jul 15 22:35:50 1987 Date-Received: Sat, 18-Jul-87 04:41:44 EDT References: <8272@brl-adm.ARPA> <3872@spool.WISC.EDU> Sender: karl@cbstr1.att.com Lines: 64 In-reply-to: lm@cottage.UUCP's message of 13 Jul 87 20:16:35 GMT lm@cottage writes: > Another thing you can do is to have light weight processes. The idea is > this: run more than one process within a single process's address > space. Switching between these processes is little more (a white lie) > than saving the old registers and throwing in the new ones. All the > other baggage is unchanged, resulting in a faster context switch. I would disagree a bit on terminology. The separation of a single process' data space into multiple schedulable entities is closer to what one thinks of as a "thread." MACH is implementing such things, though at times getting info on exactly what/how they're doing it is very difficult. One thinks of the various lines of execution through the single space as threads, with the whole space being a process or (as I remember the MACH terminology) a "task." In fact, I recall a paragraph in a MACH paper noting that a MACH task with a single thread is effectively identical to a UNIX "process." Lightweight processes, on the other hand, are processes whose purpose is to carry less baggage around in an absolute sense, and are by no means necessarily related to the separation of one space into several lines of execution. They have a bunch of advantages over "monolithic" processes (such as the typical UNIX process paradigm), such as being easy to write (a lightweight process is usually designed for a very small, closely-defined problem, rather than trying to solve several problems at once as one does in monolithic processes), their overhead is smaller, and the scheduling latency is more readily controlled and typically made much shorter. This makes them extremely useful for (e.g.) real-time control systems, an area where standard UNIX mechanisms have almost always been insufficient. Here's a short bibliography of related papers on the subject, taken from my MS thesis which was on just this sort of topic (though my purpose was more seriously involved in system performance improvement aspects of lightweight processes, rather than their general structure): Baron, Black, Bolosky, Chew, Golub, Rashid, Tevanian, and Young, "MACH Kernel Interface Manual," CMU Dept of Computer Science, October 1986. Try to get a more recent edition of it; thread information is (to be kind) sketchy in the older versions. Brooks, E.D. III, "A Multitasking Kernel for the C and FORTRAN Programming Languages," Lawrence Livermore Laboratory, Univ of California, September 1984. [thread implementation inside standard C & FORTRAN.] Kepecs, J. and M. Solomon, "A Simplified Operating System for Distributed Applications," 3rd PODC Conference Proceedings, 1984. [network system with minimal kernel support (lightweight processes) based on msg passing.] Rovner, P., R. Levin, and J. Wick, "On Extending Modula-2 For Building Large, Integrated Systems," DEC Systems Research Center, Jan 1985. [thread implementation in modula-2.] Schwan, K., T. Bihari, B.W. Weide, and G. Taulbee, "High-Performance Operating System Primitives for Robotics and Real-Time Control Systems," The Ohio State Univ Dept of Computer Science, July 1986, report # OSU-CISRC-86TR1KS (to appear in ACM Transactions on Computer Systems, 1987). Look 'em all up, they're all interesting. Cheers, Karl