jacob@hpfclo.UUCP (09/05/84)
First, I'd like to apologize for posting a note out of context (Requests for
Conc Proc Mgmt Pak Info). Since I did get a few "I'm interested", as well as
a few "What on Earth are you talking about?" mailings, I'm posting a more
complete note now. To help me keep this organized, I'm putting it into the
"question/answer" format.
Q. DO I REALLY WANT TO READ THIS?
A. If you are running the Hamburg Modula-2 compiler under VAX/VMS (or
Eunice), you should; if you are running another compiler under VAX/VMS
(or Eunice), you might; if you are not on VAX with at least a VMS lining,
the package itself is useless to you, but you might be interested in it
anyway.
Q. WHAT ARE WE TALKING ABOUT HERE?
A. A Concurrent Process Management Package, poetically named "CPMP."
Q. WHAT FUNCTIONS DOES IT PROVIDE?
A. There are basically five categories of functions:
Process management;
Shared memory management;
Signal management;
Process lock management (mutual exclusion);
Pipe management;
1. PROCESS MANAGEMENT
I don't remember the procedure names for this part, since it was
written by my partner, Kevin Mitchell (same address, see end of
letter). But basically, there are routines to start a process (by
that I mean start a VMS subprocess, not just enable a coroutine);
terminate or suspend a process; put a process into hibernation,
possibly with a scheduled awakening time; enable/disable Control-Y
(VMS's program interrupt key); perhaps a few other routines that I
don't recall. There are also some built-in behavior patterns that
automatize things a little: for example, death of a parent process
causes death of all of its child processes (just like with VMS
subprocesses), a parent process gets notified of a child's
termination (as far as I can remember -- I've no access to our
documentation right now), etc.
2. SHARED MEMORY MANAGEMENT
By "shared memory" I mean "memory shared between processES," not
"between processORS," as the term is used in VAXClusters. It works
just like Modula-2's ALLOCATE and DEALLOCATE routines:
AllocateShared returns a pointer to a chunk of shared memory of
requested length, and DeallocateShared releases it. There are also
one or more routines to initialize the shared memory, etc. (this whole
part was also written by Kevin).
3. PIPE MANAGEMENT
Pipes can be used to send data between processes. The routines are:
OpenPipe and ClosePipe;
ReadPipe and WaitAndReadPipe;
WritePipe and WritePipeAndWait.
(We tried to make routine names self-explanatory, so it's much easier
to list the functions when the names are available...). Pipes are
implemented using VMS mailboxes.
4. SIGNAL MANAGEMENT
Signals are the same conceptually as they are in Wirth's definition,
but there is a little more control over them. The routines are:
InitSignal;
SendSignal and ClearSignal;
Wait, WaitAndClear (this is what Wirth's WAIT does).
(There may be one or two more, I don't remember, but these should
give you the idea.) Signals are implemented through VMS Global Event
Flags.
5. LOCK MANAGEMENT
For you theoretical types, a lock is a variation of a semaphore.
There are two major differences: only the process that locked a
resource may unlock it (any process can "up" a semaphore -- i.e.
perform the P operation, -- regardless of which process "downed" it
-- i.e. performed the V operation); and there are SEVERAL EXCLUSION
LEVELS.
For example, several processes can request that a resource be locked
for concurrent reading, and that will be granted. But a request to
lock that resource for writing will be blocked until all the reading
processes unlock it.
The routines are:
Lock and WaitAndLock;
Unlock.
Locks are implement though VMS Locks.
Q. WHY COULDN'T YOU JUST USE WIRTH'S COROUTINE PACKAGE?
A. Well, we have a multi-tasking operating system, VMS, which can handle
concurrent processes. The only problem is that it is hard to use the
facilities, especially from a high-level language. Wouldn't it be nice
if a high-level language included concurrency? Then Ada and Modula-2
came out. A pretty nice Modula-2 compiler arrives at Northwestern.
Eagerly, I read the book on the language, and try to write a basic
Producer/Consumer program. Guess what -- it doesn't work the way it is
supposed to.
Originally, I thought that the basic coroutine implementation was at fault.
I have recently received a mailing from Joe Hicks, at Burroughs Austin
Research Center, which indicates that it probably is a bug in the
TRANSFER statement.
Anyway, we felt cheated. We wanted concurrent processes, the language
itself provided some utilities for them, but the implementation was
limited to coroutines. So we wrote CPMP. There was a nice spin-off,
too: we also created interfaces that allow the routines to be called
from other languages, notably VAX/VMS Pascal 2.x, the most commonly used
language in the EECS Dept. at Northwestern.
Q. WHY CAN'T I RUN IT ON A MACHINE OTHER THAN A VAX?
A. Because the package is written in Macro-32, VAX's native assembly language.
Q. WHY CAN'T I RUN IT WITHOUT USING VMS?
A. Because it uses VMS System Services.
Q. WHAT'S SO SPECIAL ABOUT THE HAMBURG COMPILER?
A. Not much. As I said, the package itself is written in assembler. If
you don't have a Hamburg compiler, you might need to change the syntax
in the definition modules that interface with the assembly-level
routines. Other than that, the package should still work.
Q. CAN THE ROUTINES BE CALLED FROM OTHER LANGUAGES?
A. Yes. We have only experimented with Hamburg Modula-2, VMS Pascal 2.x,
VMS FORTRAN, and VMS Macro-32 (the assembler).
Q. IS IT AVAILABLE?
A. Good question. I'll ask my advisor when I get back to Northwestern
(which will be in mid-September).
Q. WHAT SORT OF TESTING HAVE YOU DONE?
A. We are writing a multi-user Star Trek game. It's not finished yet, but
many parts that use CPMP have been tested. As the result, several bugs
have been removed, and some functionality has been added.
Q. WHAT ABOUT DOCUMENTATION?
A. We have a manual, examples, and well-documented source code.
Q. IS THE DOCUMENTATION ANY GOOD?
A. I like it.
Q. HAS ANYBODY OUTSIDE NORTHWESTERN USED IT YET?
A. No. As I said, I don't even know if it can be made available. Either
way, though, both Kevin and I would be willing to discuss the experience
with someone who might be working on something similar (perhaps under
UNIX).
Q. WHO SHOULD I CONTACT ABOUT MORE DETAILS?
A. I'll be on the net until September 14. If you don't think it will get
to me by that time, please don't send it electronically. If you send it
from an ARPA site, please give your U.S. Mail address -- I CANNOT SEND
MESSAGES TO ARPA!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
My U.S. Mail address is:
Jacob Gore
EECS Dept.
Northwestern University
2145 Sheridan Road
Evanston, IL 60201 (USA)
My advisor's address is:
Dr. Stephen S. Yau
Chairman, EECS Dept.
Northwestern University
2145 Sheridan Road
Evanston, IL 60201 (USA)
-------------------------------------
Jacob Gore
Normally at Northwestern U. Comp. Sci. Res. Lab
Currently at Hewlett-Packard Fort Collins Systems Div.
inhp4!hpfcla!jacob
VMS, VAX, VAXCluster, Macro-32 are likely to be trademarks of Digital Equipment
Corporation.
UNIX is a trademark of AT&T Bell Laboratories.
Pipe is a trademark of Romanvs Plvmbvs SPQA (:-).