Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!cat.cmu.edu!jps
From: jps@cat.cmu.edu (James Salsman)
Newsgroups: comp.sys.transputer
Subject: Re: choosing parallel languages
Message-ID: <5751@pt.cs.cmu.edu>
Date: 4 Aug 89 01:17:20 GMT
References: <8908011650.AA12679@kanga.cs.umass.edu.edu> <5726@pt.cs.cmu.edu> <1948@harrier.ukc.ac.uk>
Organization: Carnegie Mellon
Lines: 61

In article <1948@harrier.ukc.ac.uk> arc1@ukc.ac.uk (A.R.Curtis) writes:

> occam has compile-time allocated memory. It deals solely with *real*
> memory, and none of this nice run-time virtual memory.

By "virtual memory" do you mean "allocatable heap storage"
or "memory paged out to disk"?  Occam can do both.  A
Transputer OS should provide a process for these functions.

> [In reply to the idea of using process abstraction for an
>        "allocation server" -jps]
> Ok, so how do you provide a memory allocation server to handle
> completely arbitrary types? You can't, can you? But I can do this in
> C, can't I?

I can tell that you aren't an Occam programmer because you
don't know about CHAN OF ANY and PORT OF ANY -- these
protocols map everything back and forth into BYTEs.

In C, malloc returns a char pointer, while in the more
logical Occam, typelessness is declared as "anarchic
protocol."  I love that term!  "Anarchy" expresses what
dynamic allocation does to the semantics of the language
quite well.

> Also, allocating a lump of memory yourself as the heap has nasty
> drawbacks. The size depends on how much memory is on the processor.
> Less memory, less space - how do you allocate according to memory
> availability? You can do it manually, but that stinks.
> It means that all of this lump has been removed from the available
> pool of memory.

Every heap must be allocated some time.  With Occam, you can
place your allocation process on a transputer that's next to
a disk (for swapping) or you can have a network of heap
processes, one on each processor.  In that sort of a system
you can have a huge virtual address space with a distributed
index.  Overflowed heap proceses can store on nearby
processors, and the "load" can be balanced or optimized
concurrently with the client processes.

> Why not let the system do the allocation for you?

Because it's just as easy to do it yourself.

> You can't provide a
> server which will (de)allocate any arbitrary structure for you. You
> run up against the protocol problems of occam at high speed there,
> and the results are messy, because you can't specify arbitrary data
> types.

It's hard for me to believe that you haven't heard of the
ANY protocol.  Why do you post if you don't know what you're
talking about?

:James

Disclaimer:  The usual.
-- 

:James P. Salsman (jps@CAT.CMU.EDU)