jfjr@mitre-bedford.arpa (07/13/87)
I have been seeing "threads" and "light weight processes" in a Unix
context but I am not quite clear exactly what these terms mean in this
context and how such things are done. I thirst for enlightenment
Jerry Freedman, Jr
jfjr@mitre-bedford.arpalm@cottage.WISC.EDU (Larry McVoy) (07/13/87)
In article <8272@brl-adm.ARPA> jfjr@mitre-bedford.arpa writes: > > I have been seeing "threads" and "light weight processes" in a Unix >context but I am not quite clear exactly what these terms mean in this >context and how such things are done. I thirst for enlightenment Listen, oh, Grasshopper, and ye shall learn. A process carries with it a certain amount of baggage. Under UNIX, this baggage is relatively small but still not negligible. The baggage is stuff that the OS needs to reference when performing services on behalf of the object. A context switch is (as you probably know) when one process is stopped and another process is started. Part (a substantial part) of the work is moving the old process's baggage out and the new process's baggage in. This is pure overhead, it does no work so far as the user is concerned. Consequently, we would like to minimize the amount of time spent doing context switches. One thing you can do is to make the period between switches very long. Unix does this to a certain extent - the timeout period is usually about a second. This makes interactive response suffer but more "work" is done. 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. There are a lot of good reasons to do this. MACH, a UNIX replacement, is trying to split up the kernel into multiple light weight processes. They have papers that spend a fair bit of effort explaining the concept. Hope this helps, Grasshopper. Larry McVoy lm@cottage.wisc.edu or uwvax!mcvoy
jbn@glacier.STANFORD.EDU (John B. Nagle) (07/14/87)
This is an old issue, although it's new to the UNIX world. Another
terminology one sees is that of "weak fork" and "strong fork". The
UNIX fork is a "strong fork"; the new process gets its own data space
and operating system context. A "weak fork" operation has been provided
in many operating systems as an aid to programs that require internal
multiprogramming. A weak fork operation creates a process which shares
data space with the old process (although it probably needs a new stack).
One then has two processes operating on the same data. Languages such
as Modula II, Ada, Mesa, and Cedar, which support a shared-memory model
of multiprogramming, can usefully use such an operating system primitive
(and usually have to fake it in painful ways when it isn't present.)
Generally one thinks of weak and strong fork operations as being
available to user programs. But the operating system needs processes
too. The UNIX kernel originally had no processes of its own, but over
time, some have been hacked in (and "hacked" is definitely the right
word here). With the ever-increasing demands made on the kernel
(particularly networking and windowing support) the desire for the kernel
to assume a more active role rather than being merely a protected subroutine
library increases. Thus, means of efficiently giving the kernel some
processes of its own so it can further its own goals instead of just
servicing user requests are being invented. "Lightweight processes"
are one of these; Richie's implementation of "streams" are another
way of cleaning up the kernel's internal multiprogramming.
Personally, I'd like to see faster context switching, faster
gatekeeping, more process switches, and smaller kernels. But since the
triumph of vanilla hardware, this is a faint hope.
John NagleKarl.Kleinpaste@cbstr1.att.com (07/16/87)
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
aglew@ccvaxa.UUCP (07/17/87)
...> Lightweight processes and threads? What do threads gain you over processes that share all the appropriate data segments - code and data, with private stack? I mean, look at what is expensive in a context switch. Basically, it is manipulating the run queues and other scheduler data structures - and changing the memory map, so that the new process lives in its own address space, and can have a private u at a fixed address. If threads are schedulable entities, they have to have some run queue overhead. So all you can win on is the map change, which is expensive not only for the instruction sequence that changes the map itself, but also for side effects on cache, etc. (Even with process tags). But if processes are tagged as living in the same memory map, then you don't need to do the map change if it isn't necessary. So: how do threads differ from an improved process model? --- BTW fork() times really aren't an issue. In a decent system you can create process templates, fill them with the appropriate data, and only have to make a few changes to them at fork() time. They can be quickly reused.
dg@wrs.UUCP (David Goodenough) (07/17/87)
In article <302@cbstr1.att.com> Karl.Kleinpaste@cbstr1.att.com writes: >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." ..... Lots more deleted What a *BEAUTIFUL* idea - multi-threaded FORTH: since FORTH has such a simple "context": little more than a program counter & a couple of stack pointers, a context switch could be done with about 10 instructions. One wonders if this is in any way related to the fact that FORTH lends itself to real time applications? (Note I am not a FORTH guru, just an interested bystander who keeps his ears half open). However has anyone out there heard of a multi-tasking FORTH environment / written one / worked on one etc. etc. etc. My gut tells me to a FORTH expert it could be very interesting. -- dg@wrs.UUCP - David Goodenough +---+ | +-+-+ +-+-+ | +---+
billk@crash.CTS.COM (Bill Kelly) (07/19/87)
In article <who cares> David Goodenough writes: >has anyone ever heard of a Multitasking Forth environment? (Or written >one?) (He said something like that, anyway...) Many Forths today are multitasking. Traditionally, Forth was designed as both a multitasking and multi user environment. Bill -- -- Bill Kelly {hplabs!hp-sdd, ihnp4, sdcsvax}!crash!billk "I hate operating systems!" --GMK
allbery@ncoast.UUCP (Brandon Allbery) (07/24/87)
As quoted from <255@wrs.UUCP> by dg@wrs.UUCP (David Goodenough): +--------------- | interested bystander who keeps his ears half open). However has anyone | out there heard of a multi-tasking FORTH environment / written one / | worked on one etc. etc. etc. My gut tells me to a FORTH expert it could +--------------- The book STARTING FORTH by Leo Brodie discusses such a system, sold by a company called Forth, Inc. -- [Copyright 1987 Brandon S. Allbery, all rights reserved] [Redistribution permitted only if redistribution is subsequently permitted.] Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal,cbosgd}!ncoast!allbery <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>