Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!agate!saturn!raveling@vaxb.isi.edu
From: raveling@vaxb.isi.edu (Paul Raveling)
Newsgroups: comp.os.research
Subject: Re: THREADS, Light weight processes
Message-ID: <5568@saturn.ucsc.edu>
Date: 19 Nov 88 02:20:08 GMT
Sender: usenet@saturn.ucsc.edu
Organization: USC-Information Sciences Institute
Lines: 84
Approved: comp-os-research@jupiter.ucsc.edu


In article <5467@saturn.ucsc.edu> edler@cmcl2.NYU.EDU (Jan Edler) writes:
>
>First, I want to respond to one opinion expressed by mcvax!jack (Jack Jansen)
>in article <5354@saturn.ucsc.edu>:
>> So far nobody seems to have mentioned that LWPs are a very nice
>> mechanism to program with, much nicer than non-blocking I/O with
>> completion interrupts or polling, etc.
>
>This was also agreed to by libes@cme.nbs.gov (Don Libes) in article
><5394@saturn.ucsc.edu>:
>> I agree completely.  I recently wrote an article discussing exactly
>> this.  It showed the difficulty of writing a conceptually simple
>> program, and how it resolved cleanly into 3 threads, just a couple of
>> lines a piece.  It also discussed threads with respect to OS/2 and UNIX.
>
>Anyway, I have to say I disagree.  There are two issues here, syntactic
>and conceptual.

	On conceptual grounds I tend to agree rather than disagree.
	A virtue of processes, no matter what their weight, is
	encapsulation of logic.

	This should sound a bit like object-oriented programming.
	It turns out all that "process oriented programming" we
	did in the '70's had a lot in common with OO techniques.

>Things like constructing control blocks, checking for error conditions,
>etc., can be a real hassle in asynchronous I/O systems, ...

	I/O systems are easiest with a process-oriented approach.
	A process per device in the kernel often allows using the
	process state instead of state data saved in control
	blocks.  This also tends to radically decrease the amount of
	"critical region" code that needs exclusive access to
	shared control blocks, device interface registers, etc.

	Good interprocess communication simplifies the interface
	between client processes and i/o [device driver] processes.
	In a system such as EPOS the kernel's mechanism for queueing
	messages as event data eliminated the need for separate
	i/o scheduling queues.
	
	As the application sees it, asynchronous and synchronous i/o
	are nearly identical.  For asynchronous i/o, it supplies an
	event identier code for the kernel to use in the message
	reporting i/o completion; when the application eventually
	waits for or checks for that event, it gets the same event
	data as for a synchronous request (info such as completion
	status and number of bytes transferred).


>...  There is no reason not to provide an
>easy-to-use asynchronous I/O interface.

	You bet!

>Conceptually, both asynchronous I/O systems and LWP systems are sources
>of complexity.  Both require you to deal with language/compiler issues
>having to do with asynchronous access to shared variables ...

	I think access to shared variables is the only thing that
	may need to involve the compiler.  If the hardware guarantees
	as little as uninterrupted increment-and-test and decrement-
	and-test operations, even that can become almost trivial.

	Questions of blocking get to be potentially painful with
	LWP's.  A fairly clean answer is to use "HWP's", but be sure
	it's easy for them to communicate via messages and to share
	portions of an address space.

	Of course VERY fine-grained LWP's or short threads would
	need more language help, but practically all of the situations
	I've encountered that beg for multiple processes or threads
	have been more appropriate for "heavies".  The main virtue
	of LWP's on UNIX systems is to allow fast interprocess
	communication, fast context switching, and sharing an address
	space.  It's not that tough to provide the same facilities
	to "HWP"'s, but it takes a different kernel.


---------------------
Paul Raveling
Raveling@vaxb.isi.edu