Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ulowell!apollo!perry
From: perry@apollo.HP.COM (Jim Perry)
Newsgroups: comp.realtime
Subject: Re: Lightweight Tasks
Message-ID: <44c09a50.183dc@apollo.HP.COM>
Date: 31 Jul 89 17:22:00 GMT
References: <2153@gmu90x.UUCP> <70900004@m.cs.uiuc.edu>
Reply-To: perry@apollo.COM (Jim Perry)
Organization: HP/Apollo, Chelmsford, MA
Lines: 46
Keywords:

Here's my two cents.  First off, I think "lightweight tasks" is a corrupted
and misleading form.  The term "task" by itself embodies the concept in
question.  I don't know the origins of the term, I think it came from
IBM-land (certainly tasks occur, with this meaning, in IBM PL/I).  It (the term
and the concept) was used extensively in the Dartmouth Timesharing System
(DTSS), mid-'60's.  Multitasking predates time-sharing (sometimes called
multiprocessing, but that gets confusing when you let multiple CPUs into the
picture), let alone UNIX.

The historical origins do come from I/O optimization, but not particularly
network protocols.  Mainframes (another line of discussion) were very concerned
with "throughput" -- getting as much data as possible processed as fast as
possible, and tended to have fancy hardware to handle I/O in parallel with
CPU processing.  Instead of waiting around for e.g. a read operation to
complete, optimal programs would continue processing, e.g. sorting the
previous buffer.  When the read completed the program would be notified
and logically continue that alternate thread of control (temporarily
suspending the sorting thread).  This was termed multitasking, and the
abstraction of "task" applied to the individual threads of control.

With timesharing came the idea of running multiple programs, each with a
"virtual machine" -- address space, registers, etc. apparently for its own use. 
In UNIX, via Multics, this became a "process".  These systems optimize cycles by
running another process when one is blocked on I/O.  Other systems (e.g. DTSS)
maintain the potential asynchrony of I/O and thus potential multitasking within
a process.  For instance, the DTSS command line interpreter (shell equivalent)
SIMON is a single program/process.  As each new user logs on, a communication
file (similar to a pipe) connected to that user's terminal connection is passed
to SIMON, which creates a task to handle it (and thus may be handling several
hundred tasks at once).  Interactive commands (even editing, to an extent), are
handled by SIMON and a new process doesn't get created until a user explicitly
runs a program.  This scheme allows considerably more simultaneous users for the
same horsepower CPU.

Anyway, multitasking is an old and useful concept.  The same results can be
achieved with multiple communicating processes, especially in the presence of
shared memory and IPC, but in UNIX, for instance, this can be expensive. 
"Lightweight process" seems to have been coined to discuss tasks by analogy to
UNIX (nee Multics) processes.  It is possible through various nefarious schemes
to create a semblance of multitasking within a UNIX process, and various such
schemes exist; hopefully future iterations will make it even easier.

-- 
Jim Perry   perry@apollo.com    HP/Apollo, Chelmsford MA
This particularly rapid unintelligible patter 
isn't generally heard and if it is it doesn't matter.