🚀 go-pugleaf

In article <1991May20.185351.17114@ecrc.de> veron@ecrc.de (Andre Veron) writes:
>
>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. ....................................................

    Why do you think so?


>....................... 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.

    Files???  Contextwise, a MACH task is (mostly) a collection of VM regions. 
    Considering the way MACH manages memory (page aliasing), creating a new
    task/context should be relatively cheap.
>
>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...

    I am not sure what you mean by "private", since you also indicate that a 
    "private" region will be read-shared with the parent task.

    What you are really looking for is a VM_INHERIT_MOVE inheretance attribute
    in addition to VM_INHERIT_SHARE, 0VM_INHERIT_COPY, VM_INHERIT_NONE already
    provided by MACH.  While it would be nice to have one supported by MACH,
    you should be able to achieve similar results with VM_INHERIT_COPY and 
    vm_deallocate(parent_task).  

> 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.

    Looks like you just reinvented the MACH :)
>
>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