The S member represents the name of the data structure that this folder is part of, e.g. the name of an array. For an array, the X member contains the indices. The system includes a definition for NUM_X in the header file. We provide NUM_X equal to three, but it can be changed if the application demands it.

SYMBOL memo_symbol()
Memo_symbol generates a unique SYMBOL. It will not be the same as the value returned by any other call to memo_symbol(\or to any "small" integer (unless the system has run for a very long time). Small integers are available for predefined symbols.

Memo_write puts a memo into a folder named by the key. If a folder by that name does not already exist, one is created. The contents of the memo are the len bytes beginning at address block_addr.
Memo_get returns a pointer to a memo removed from the folder named by key. The length of the body of the memo m can be found by calling memo_len(m). Memo_get blocks until there is a memo present in the folder. (If the folder does not already exist, it is created.)
Memo_get_copy is the same as memo_get except that the memo is not removed from the folder; it is copied and the copy is returned. If there is more than one memo in the folder, a copy of one of them is returned.
Memo_get_skip is a non-blocking version of memo_get. If there is no memo immediately available, memo_get_skip returns NULL. And memo_get_copy_skip is the same as memo_get_copy except that if there is no memo immediately available, memo_get_copy_skip does not block but returns a NULL pointer.
All forms of memo_get return a pointer to a block of dynamic storage. The contents of the memo are accessed through the pointer. For example:

Memo_free frees the dynamic storage that a memo occupies.

Memo_alt is a version of memo_get that returns a memo taken from one of a list of alternative folders. Parameter key_list points to an array keys, the names of the folders to be examined. The length of the list of keys is len_key_list. As with memo_get, memo_alt blocks until a memo can be returned.
Memo_alt_skip will return NULL if no memo was found in any of the specified folders. Result parameter one_found will give the index in key_list of the name of the folder from which the memo was taken, or minus one (-1) if no memo was found (by memo_alt_skip).

Memo_strict_alt_skip is a variant of memo_alt_skip. The distinction is this: alt_skip will not return NULL if one of the folders named has a a memo in it from the time alt_skip is called until it returns; that is, alt_skip is required to look in each folder before returning NULL, and if one of the folders has a memo in it when alt_skip looks, alt_skip is not allowed to return NULL. Memo_strict_alt_skip will not return NULL unless there is some instant of time between its call and return when none of the folders contains a memo; that is, strict_alt_skip behaves as if it looks in all folders simultaneously.

These procedures will link a memo into the system queues that a user program retains a pointer to. In shared memory implementations, the system may deliver the memo to another user. These routines are therefore not safe - the sender can easily cause mischief to the system or the receiver; they are provided to increase efficiency.
Memo_put is the same as memo_write, except \ that the already existing memo data structure is used, rather than a new one being created.
Memo_put_delayed behaves like memo_put(key2,memo) with the following difference: although memo_put_delayed returns immediately, the memo is not actually delivered until one or more memos are present in the folder named key1.
Memo_alloc allocates a Memo structure of the specified length. It can be used to avoid double copying, first into a user buffer and then into a memo. It should be placed in a folder by calling memo_put or memo_put_delayed.
Memo_replace replaces the memo in the folder it was taken from. It is undefined if the memo was created by memo_alloc.

Memo_key returns a pointer to the name of the folder a memo was removed or copied from by memo_get... or memo_alt.... This will be a field of the memo's header; the pointer should not be used after the memo has been freed, replaced, or put. Assigning indirectly through this pointer may make memo_replace malfunction.
For example:

Locks. Naturally, an explicit lock can simply be represented by an empty memo in a folder.

FOLDER_NAME lock;
MEMO q;
...
memo_write(lock,"",0);
...
q = memo_get(lock);

Semaphores. The simplest implementation of a counting semaphore is identical to a lock, except that to initialize the semaphore, a process places as many empty memos in the semaphore's folder as initial count.
Unordered queues. A folder is an unordered queue, so if order is not vitally important, processes can communicate simply by passing memos through a folder.

Job Jar. An important use of an unordered queue is as a job jar. The memos in the job jar indicate tasks to perform. Whenever a process requires more work to do, it pulls a memo out of the job jar. Whenever a process creates more work to do, it drops memos in the job jar. It is often convenient to have one job jar for each process and one common jar for all. The individual job jars are used for operations that must be performed by a particular process, e.g. file I/O - a file is typically open in only one particular process.
Memo_alt can be used to get a memo from either the local job jar or the common one.

Futures and I-Structures. A future is an assign-once variable used to communicate between a producer (typically a subroutine) and a consumer (its caller). Both the producer and consumer may run in parallel, with the consumer only being delayed if it attempts to fetch from the variable before it has been assigned. An I-structure (an "incremental structure") is a collection (e.g. an array) of futures. I-structures were invented for dataflow hardware [ARVI80].
In Memo, any folder that will have only one memo ever placed in it may correspond to a future. The consumer executing a memo_get, memo_get_copy, or memo_alt fetching from that folder will be delayed until the value has been produced. The folder will vanish once the memo is removed.
Since it is usually better not to block an entire process, the consumer can delay a memo for the job jar in the future's folder which will trigger the desired computation when the data becomes available:
FOLDER_NAME future,job_jar;
...
memo_write_delayed(future,

Dataflow. Dataflow programming triggers execution of code when its operands become available [ACKE82] [ARVI86] [DAVI82] [DENN80] [TREL82] [VEEN86]. The Memo system facilitates dataflow programming by providing the memo_write_delayed procedure. Assume the operands are futures. One simply arranges to have an operation dropped into a job jar when an operand memo arrives in a folder, thus:
FOLDER_NAME operand,job_jar;
...
memo_write_delayed(operand,

If the operation requires more than one operand, then the operation can poll for each of the operands (e.g. by memo_present) and delay itself in absent operands' folders until all are available.

Reactive Objects. A reactive object is an object that executes only in response to messages it receives. Reactive objects are central to the Actors model of parallel computation [AGHA86] [ATHA86] [ATHA87] [ATHA88] [BODE88]. A reactive object can be implemented with a job jar folder plus one input folder per object. A memo containing the object is delayed on its input folder. When an input memo arrives, the object is placed in the job jar. Eventually some process fetches the object from the job jar and executes its code, which reads an input message and responds to it. (For efficiency, it is better to loop reading all available input messages with memo_get_skip, rather than delaying the object after processing each one.)

Ordered queues.The simplest implementation of an ordered queue is an array of futures. For example, the producer can write memos into folders thus:
#define QUEUE ...
...
FOLDER_NAME dest;
int outpos = 0;
dest.S = QUEUE;
dest.X[1] = dest.X[2] = 0;
...
while (1) {

Barriers. In parallelizing a loop, it is often important to synchronize the processes executing the loop at one or more points within it using a barrier. If a barrier is initialized with a count N, then N processes must wait at the barrier before any of them are allowed to proceed. The barrier is automatically reinitialized so that they can synchronize over and over again at the same barrier. In Memo, a barrier can be implemented with two folders and a single memo containing an integer count. The presence of the memo in a folder allows the processes to proceed past the barrier.
The processes alternate which folder they look for the memo in. When a process comes to a barrier, it gets the memo and decrements the count in it. If the count is greater than zero, this is not the last process to arrive, so it puts the memo back and tries to get a copy of the memo in the other folder, which is not present yet.
If the process decrements the count to zero, then this is the last process to arrive. It puts a memo with the full count of the number of processes to synchronize into the other folder and continues executing.
Code for this follows:
FOLDER_NAME barrier[2] = {{BARR0,0,0,0},{BARR1,0,0,0}};
int which=0,num_at_barrier=NUM_TO_SYNCHRONIZE;
...
/* initialize the barrier*/
memo_write(barrier[0],&num_at_barrier,sizeof(int)\;
...
while (TRUE) {