Browse Prior Art Database

Mapped Static Allocation for Parallel Subprograms

IP.com Disclosure Number: IPCOM000037122D
Original Publication Date: 1989-Nov-01
Included in the Prior Art Database: 2005-Jan-29
Document File: 5 page(s) / 79K

Publishing Venue

IBM

Related People

Darema-Rogers, F: AUTHOR [+3]

Abstract

A method is described herein which extends the techniques disclosed in 1 to correct a serious deficiency. Using the technique previously disclosed, it is in general quite difficult to program parallel subroutine packages, i.e., parallel subprograms. The technique described here, Mapped Static Allocation, addresses a major part of that problem: storage allocation for parallel subprograms.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 34% of the total text.

Page 1 of 5

Mapped Static Allocation for Parallel Subprograms

A method is described herein which extends the techniques disclosed in 1 to correct a serious deficiency. Using the technique previously disclosed, it is in general quite difficult to program parallel subroutine packages, i.e., parallel subprograms. The technique described here, Mapped Static Allocation, addresses a major part of that problem: storage allocation for parallel subprograms.

While there are other methods for providing the necessary support, the technique disclosed here has a number of advantages:
1. No compiler modifications are necessary for languages

like FORTRAN

which have static data allocation.

(Image Omitted)

2. With appropriate preprocessor support, it

is easy to use.
3. It requires no code changes to accommodate execution by

varying

numbers of processes or processors.
4. It is more efficient, in that less address arithmetic is

required

to access required data.
5. It can be used in languages which, unlike FORTRAN, have

dynamic

storage allocation, for storage which must be statically

allocated.

A parallel subprogram is a body of code which can be invoked by a higher- level program and performs some function using multiple processes. An example of such a parallel subprogram might be a solver of simultaneous linear equations.

When implemented in a shared-memory context such as that of 1, a parallel subprogram must have, associated with each of its invocations, some storage which is global to all the processes it uses. This must be available not just for programmer-visible temporary storage, but also for lock and other synchronization information used to control the flow of processing among the multiple processes of the parallel subprogram. Such storage is referred to herein as partially shared storage.

(There must also be a way for multiple threads of control to become active within the parallel subprogram itself, a problem with several possible solutions; it is not addressed here.)

If the higher-level program is itself parallel, multiple copies of the parallel subprogram may be simultaneously active. This fact distinguishes partially shared storage from completely global storage: partially shared storage must be accessible by some of the processes, but must not be accessible by all. In

1

Page 2 of 5

particular, each separate active copy of a parallel subprogram must have partially shared storage distinct from every other active copy. Therein lies the problem addressed here, since the technique of [1] directly provides two types of memory allocated to a parallel program: completely local memory, accessible only by one process, and completely global memory, accessible by all processes.

Since parallel subprograms should, for generality, be able to call other parallel subprograms, the situation when a higher-level program itself is parallel is not special, but rather the normal case that must be supported to any level of nesting.

The technique presented here makes use...