Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!mcsun!unido!ecrc!ecrc!veron
From: veron@ecrc.de (Andre Veron)
Newsgroups: comp.os.mach
Subject: Re: Efficient copying from task to task
Message-ID: <1991May20.185351.17114@ecrc.de>
Date: 20 May 91 18:53:51 GMT
References: <1991May17.074526.19128@sics.se> <3319@sirius.ucs.adelaide.edu.au>
Sender: news@ecrc.de
Reply-To: veron@ecrc.de (Andre Veron)
Distribution: comp
Organization: ecrc
Lines: 65


Copying data form task to task with data mapped at the
same virtual address in  the two tasks is problem we have
encountered when trying to design a Parallel Prolog-like System.

We wanted to have a machinery for creating dynamically tree of processes where:
1/**Every process which has forked off children is suspended until its
children terminate. 
2/**The children are created with a copy of a  part of the parent  data space. 
3/** The size of the data to be copied is not fixed and can easily be some
(tens of) megabytes big.
4/** The data must be mapped at the same virtual adress both in the parent 
and the children.
5/** Not all the data which is copied in a child's space is read or written
by the child. Locality in the accesses or updates is expected.
6/ The processes in the tree do not need file descriptors,I/O channels
or communication ports. 

Because of 3/ and 5/ the eager copying of UNIX fork put UNIX out of the game.

We then put some hope in the lazy copying of MACH.  The problem then appeared
to be that MACH as well as UNIX is not designed for applications which
need intensive forking of "threads" of computation which have their own 
separate adress spaces. The task in MACH  is a coarse grain entity which
have a whole bunch of available facilities like files, communication
port which are not always needed but are always there. A task is consequently
costly to create, to schedule and to terminate.

What we ended up with is a proposal for a new kind of thread/process
which we believe is implementable in an operating system and fits more
our needs. These threads/processes are executed in the same adress space
except in some precise regions that they personnaly own and which are copied
(lazily) form the parent at creation time. The virtual space
appears then to be "locally layered":

                             ------------- : Owned by Thread1
                             ------------- : Owned by Thread2
                             -------------
     |-----Shared space----| Private space |--------Shared space -------|
                             ------------- : ....
                             ------------- : ....
                             ------------- : Owned by ThreadN...
 Within a quantum of time allocated
to a global "task" (not a MACH task any more) context switching between
these threads/processes is cheap - the cost is the one of a unmapping 
the pages of one thread/process and mapping those of the next one.
Since the concept of private region is hardwired in the paradigm
all virtual memory handling can be done at forking time/context-switching time
when the system is in kernel mode. No additional and unelegant system calls
are need to set up  the execution environement of a newly created/scheduled
thread/process. Moreover teh resources (physical pages) allocated to a
terminated
thread can be kept by the "task" and ready to be allocated to the next created
thread/process.

If this kind of thread/process is of interest for something else than
a parallel prolog system, we would like to hear from the people interested
by them. We could then put some  pressure on operating systems designers  :->..


Andre Veron
ECRC GmbH (European Computer Research Centre)
Arabellastrasse 17
D-8000 Munich 81 FRG
email: veron@ecrc.de