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.