Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!gillies
From: gillies@m.cs.uiuc.edu
Newsgroups: comp.realtime
Subject: Re: Lightweight Tasks
Message-ID: <70900004@m.cs.uiuc.edu>
Date: 29 Jul 89 21:10:00 GMT
References: <2153@gmu90x.UUCP>
Lines: 40
Nf-ID: #R:gmu90x.UUCP:2153:m.cs.uiuc.edu:70900004:000:1989
Nf-From: m.cs.uiuc.edu!gillies    Jul 29 16:10:00 1989


Zalman Stern, Let me see if I can summarize your definition.
Lightweight tasks --
  (1) have stack & register set.
  (2) have no address space, signal masks, uid, file descriptor tables, etc.
  (3) are also called threads, LWPs.
  (4) predate UNIX [Ed -- then why the new name?]
  (5) solve different problems than UNIX tasks.
  (6) Most LWP systems have Heavy Weight Processes too
      [Not true in Xerox DLion/Pilot/Cedar, with VM + lightweight tasks]
  (7) Some implementations of LWPs exist within UNIX processes.

I have no qualms with (1), (2), (3).  About (4) -- I think it is
historically correct to say that network protocols were a major
impetus for developing lightweight tasks (in the three systems I
worked with -- PDP11 MIT V7 TCP/IP/Telnet & C-gateway, IBM PC/IP, and
Xerox Pilot OS, this was precisely the reason for them).  Certainly
lightweight tasks allow faster response time to realtime events (such
as network packet arrivals and ack timeouts).

As for (6) and (7) -- it is possible to layer heavy weighted-ness upon
lightweight tasks, by adding status blocks to the lightweight task.
This is what is done in the Xerox DLion with the Pilot kernel.

The least successful lightweight tasking system I know of was built
within heavyweight UNIX tasks.  If you must schedule a heavyweight
UNIX task before you can get to a lightweight task, then I call this
a heavyweight tasking system.

We can quibble about whether lightweight tasks were a reaction to the
slowness of UNIX tasking; It is certainly true that UNIX tasks are
inappropriate for a well-structured layered protocol implementation,
and hence most of the protocol implementation in 4.2BSD ended up in an
awful place -- in the kernel.  Lightweight tasks were used in other
systems to get this code out of the UNIX (and other) kernels.


Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801      
ARPA: gillies@cs.uiuc.edu   UUCP: {uunet,harvard}!uiucdcs!gillies