Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!think!ames!ptsfa!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew From: aglew@ccvaxa.UUCP Newsgroups: comp.unix.wizards Subject: Re: light weight processes and threads Message-ID: <27300011@ccvaxa> Date: Fri, 17-Jul-87 16:51:00 EDT Article-I.D.: ccvaxa.27300011 Posted: Fri Jul 17 16:51:00 1987 Date-Received: Sun, 19-Jul-87 01:20:11 EDT References: <8272@brl-adm.ARPA> Lines: 27 Nf-ID: #R:brl-adm.ARPA:8272:ccvaxa:27300011:000:1118 Nf-From: ccvaxa.UUCP!aglew Jul 17 15:51:00 1987 ...> 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.