The Task distribution preprocessor (TDP)

(1)

Rochester Institute of Technology

RIT Scholar Works

Theses

Thesis/Dissertation Collections

1989

The Task distribution preprocessor (TDP)

Frank McCanna

Follow this and additional works at:

http://scholarworks.rit.edu/theses

Recommended Citation

(2)

Approved b}':

Tilt' Rochestu

Inslltutr

of TKhnoloc.\'

School of

Computu

Scltn~

Tht' Task Distribution

P~procnsor

(TDP)

by

Fronl

McCOMO

A thesis, submined to

1nt

Faculty of tht School of Computer Science.

in

paniaJ fulfillment of tht requirements for tht degree of

Master of Scienet

in

Computer Science.

Dr.

P~ur

Lun

Dr. Andrnf' KilcMn

Peter Anderson

(3)

TITLE OF THESIS:

The Task Distribution Preprocessor

I, Frank McCanna, hereby grant the Wallace Memorial Library, of RIT,

and all other persons or institutions, permission to reproduce the

material contained in this thesis document.

I make no restriction

against use of reproductions of all or part of this thesis for

commercial use or profit provided that proper credit is given to

the original author of the material.

Frank McCanna

Date:

(4)

---"""""-+-'~-r-""""'-+---Abstract

This document

describes

a software processor used to generate portable and

efficient multiprocess programs that run on _{UNIX operating} systems. The processor is

designed tobea convenient methodfor converting single process Cprograms into distri

buted multiprocess C programs. Another goal is to have the processor used as a

"back"end

or "platform" _{for multitasking languages} andcode generators.

Efficiency

is

targeted toward multiprocessor systems that provide facilities for sharing physical

memory between processes _running on separate CPUs.

Portability

is achieved with the

use ofthe

highly

portable UNIX operating system and itscompanion

C

language. The C

language is used asboth theinput andoutputlanguage fortheprocessor. UseofC as an

object language gives _portability to the generated multitask program.

Using

C as an

input

language,

simplifies the interface with_{multitasking languages} and code generators

as well as _minimizing changes _necessary when _{converting C}

language

single task pro

grams tomultitask programs. Initial implementation oftheTask Distribution Preproces

sor will generate

C

codethatcan becompiled andrunon_{any UNIX}systemthatprovides

message_{passing facilities.}

(5)

The Task

Distribution

Preprocessor

(TDP)

-n

Acknowledgements

My

thanks to Dr. Peter Lutz and Dr. Andrew Kitchen fortheir support andideas. I

also want to thank _my wife

Anju

S.

McCanna,

for suggestions _concerning the _writing

styleofthe "Purpose" section intheintroductionto thisdocument.

Key

Words

and

Phrases

Key

Words in this document include:

Language, Parallel, Distribution,

Con

currency,

Multiprocessing, C,

Preprocessor.

Key

Phrases inthis document include:

Multiprogramming

Languages,

C Preproces

sors,

Multiprogramming

Platforms.

(6)

The Task Distribution Preprocessor

(TDP)

- iii -Tableof

Contents

Table of

Contents

1

INTRODUCTION

AND

BACKGROUND

1

1.1 Purpose 1

1.2 Previous Work 4

2

PROGRAMMING OPTIONS

18

2.1

Specifying

aTask 18

2.2

Specifying

Shared Data 18

2.3 Unshared

Memory

19

2.4 Stack

Memory

20

2.5

Library

Functions 20

2.6

Synchronizing

Tasks 21

2.7

Building

As A Single Task 24

2.8 Second Level

Modularity

Conflicts 24

2.9

Other Synchronization Constructs 27

3 PROCESSOR SPECIFICATION 29

(7)

The

Task

Distribution

Preprocessor

(TDP)

- iv

Tableof

Contents

3.1 TDP

Processing

Diagrams

29

3.2 TDP

Processing

Description

31

3.3 Processor Design 36

3.4

Achieving

Data Alignment 36

4 RUNTIME PLATFORM 43

4.1 Runtime Description 43

4.2 Runtime Diagrams

55

4.3 TDP Runtime

Library

58

5 VERIFICATION AND VALIDATION 60

6

CONCLUSIONS

62

6.1 Problems EncounteredandSolved 62

6.2 System Deficiencies 62

6.3 Suggestions for Future Extensions 62

6.3.1

Limiting

theTransferofData 62

(8)

(TDP)

Table

of

Contents

6.3.4

Exec()

Overhead

Reduction 65

6.3.5 Detectionof

Inefficient

RemoteCalls 67

6.3.6

Dynamic

Linkage

68

6.3.7

Full Code Duplication

69

6.4 Related

Thesis

Topics fortheFuture 70

6.4.1

Automatic

TaskGenerator

70

6.4.2 Portable

Multitasking

Languages 71

7 BIBLIOGRAPHY 73

APPENDIX A: Example Program- InputtoTDP 78

APPENDIX B: Example Program-

Output

_ofTDP 81

APPENDIX

C:

Running

the Example Program 92

APPENDIXD: Walk-Through for Example Program 93

List ofFigures

Figure 3-1 ProgramLoad Module CreationwithoutTDP

29

Figure 3-2 Multiple Load Module Creation

Using

TDP

30

(9)

The

Task Distribution Preprocessor

(TDP)

-vi

Table

of

Contents

Figure

4-1

Communication

withtheFork Server

49

Figure 4-2 Creation

of

Child

Task 50

Figure 4-3 Tightly-Coupled Configuration 51

Figure 4-4 Child Task Termination 53

Figure 4-5

Loosely-Coupled

Run Time System 55

(10)

(TDP)

- 1

-1 INTRODUCTION AND

BACKGROUND

1.1 Purpose

(TDP)

is a _programming system for multiple

process programs. TDP is designed to provide maximum _efficiency and _{portability in}

multipleprocess programs _running on

tightly

coupled multiprocessorUNIX systems. A

"tightly

coupled"

multiprocessor systemis one whichprovides parallelism intheexecu

tion ofkernel code but maintains a single file system and _{controlling operating} system

[BAC]. The _efficiency ofthe TDP system also depends on amultiprocessor systemthat

allows the_sharing of physical_memory betweenuserprocesses.

Along

with efficient use

of

tightly

coupledmultiprocessors, a major goalforthe TDP_system, is thatmultiprocess

programs be able to run on _{any hardware} platform _running the _{UNLX operating} system.

Portability

in

TDP,

will allow the use of inexpensive systems

during

multiprocessor

applicationdevelopment andallow ease_{in porting}theseapplications tonewhardware.

Revision E Version 1

(11)

The Task

Distribution

Preprocessor

(TDP)

2

-Section

1.1 Purpose

The Task Distribution Preprocessor essentiallyprovidesparallel constructs to the C

language

[KER]

without _changing the

language.

_{There is only} oneTDP provided func

tion to synchronizeparallel code. _{Data sharing is}provided

by

_putting all static datainto

shared memory.

Why

a task distribution preprocessor? What makesthe _multitasking platform gen

erated

by

TDP differentor superiortoother_multitaskingplatforms? Themostimportant

difference

is

that the output (and

input)

toTDPis standard

C

code that canbe compiled

on _any UNIX system. Withthe success of

UNIX,

both

industry

andacademia havereal

ized the importance of software _{portability [LAP].} It is

becoming

so important that

software development _{is very} often done _using UNLX and the C language for no other

reason than for portability. C is very often chosen over other portable high level

(12)

(TDP)

- 3

-Section

1.1 Purpose

run onthe newUNIXplatfonn. Oftenan application can_{be running} onanew platform

the same

day

aUNLX kernel isportedto theplatform[BOD].

If efficiency can _{only be} realizedwith

tightly

coupled multiprocessor _{systems, then}

what good is the portability?

Very

_simply, TDP processed applications will be

developed (formultiprocessor _systems) onsingle CPUsystemsbecause single CPU sys

tems are cheaper. Software development for multiprocessor systems can proceed on

cheap reliable single CPU systems and then moved to target multiprocessor machines

when the software has been

thoroughly

debugged and verified. When the time comes

that

tightly

coupled multiprocessor systems are _commonplace, _portability between the

makes and models ofthesemachines will alsobe_very important.

Is portability and _{efficiency really} so important that TDP be used instead of more

appropriate parallel _programming languages? TDP can, of _course, be used

by

C pro

grammers to generate parallel programs, but TDP can also _{be effectively} used as an

object

"language"

for other high level multitasking languages. Other high level

languages will

"inherit"

the _portability and _efficiency of TDP

by

"compiling" their

RevisionE Version 1

(13)

The

Task

Distribution

Preprocessor

(TDP)

- 4

-Section

1.1 Purpose

source code

into

C code thatcanthenbeprocessed

by

TDP.

1.2 Previous Work

Much of TDP is

based

on the remote call concepts presented

by

Nelson

[NEL1,NEL2],

summarized

by

Hamilton

[HAM]

and implemented

by

Birrel & Nelson

[BIR]. Aremoteprocedurecallis best described inthewordsofBirrel& Nelson:

"The idea of remote procedure calls (hereinafter called

RPC)

is quitesimple.

It is based on the observationthat procedure calls are a well-known and

well-understood mechanism for transfer of control and data within a program run

ningon a single computer.

Therefore,

itisproposedthat this samemechanism

be extendedtoprovide fortransferof control anddataacross acommunication

network."

[BIR]

Birrel & Nelson omitted two major features from their implementation that have been

addressed

by

TDP. The twofeatures are shared_memoryand parallel or"asynchronous"

(14)

(TDP)

5

Section

1.2 Previous Work

"In _summary, a shared address space between participants in RPC might be

feasible,

but since we were not _willing to undertake that research our subse

quent design assumes the absence of shared addresses. Our intuition is that

with our

hardware

the cost of a shared address space would exceed the addi

tionalbenefits."

[BIR]

In

fact,

most

implementations

ofRPC do not provide shared memory. With the

absence ofshared _memory

facilities,

remote procedure calls arelimited to call-by-value

or

"copy-in/copy-out",

no addresses as arguments or in

data,

can be shared across the

RPC. This restriction _may seem

inordinately limiting

but for some systems this limita

tion provided a _simplicity that was _very attractive. The main attraction was for use of

this scheme for heterogeneous distributed systems. Falcone

[FAL]

found Birrel &

Nelson'sschemeto_{be very} appropriatefor his

Lisp

[LIS]

based

language

for heterogene

ousdistributedsystems.

The original goal ofTDP was to _simply add shared address space for a Birrel &

Nelson - like_remote call implementation using standardUNLX andthe

C language.

The

implementation was to be similar, but more flexible than an

implementation

by

Glasser

RevisionE

Version

1

(15)

The

(TDP)

-

6

-Section

1.2 Previous Work

[GLA1,GLA2]

that copied data referenced

by

pointer arguments. The goals were

expandedto

include

parallel or "asynchronous" remote calls and an efficient implemen

tation for tighdy-coupled multiprocessor environments when the importance of this

hardware

platform

became

apparent.

LiketheBirrel& Nelson RPC system,TDPallows aprogramto _alternately runas a

single process or multiple process program without _changing the source code. Birrel &

Nelsonprovide this _capability

by linking

in function "stubs" forremote functions when

a program is built. The function stub_{is simply} afake definitionforafunctionthat, when

called, will interface with a run-time system that provides for remote execution ofthe

real function. Withoutthe function _stubs, theprogram can run as a single process. With

the stubs, the program is a multiple process distributed program. TDP provides this

capability

by

processing thesource code and _replacing remote calls withcalls that inter

face with a run-time systemthatprovides remote execution. Without TDPprocessing, a

(16)

The Task

Distribution

Preprocessor

(TDP)

- 7

Section

1.2 Previous Work

programs to utilize the advantages of multiple threads of execution while _retaining a

vehicle forsimplified

debugging

witha single process versionofaprogram.

Forparallelism and synchronizationwithshared_memory,TDPhas taken theimple

mentation restriction adopted

by

theAda language [REF]. The restriction adoptedisthat

shared _{memory is only}guaranteedtobeupdated at program synchronization points. This

restriction was adopted so that TDP could _easily provide shared _{memory for} either

loosely-coupled or tightly-coupled multiprocessors but retain high _efficiency in a

tightly-coupled environment. A quote from an article

by

Mundie & Fisher

discussing

Ada,

gives a_very complete accountoftheissue:

"Shared Memory. Another issue

facing

process-model

languages

isthedicho

tomy

between _{shared-memory} systems and message-based systems. If the

language assumes that the parallel processors share _memory, then it is con

venient and efficient to usethat shared _{memory for interprocess} synchroniza

tion andto allow multiple processes accesstosharedvariables.

However,

that

approach _virtually precludes _extending the parallel _processing scheme to

loosely

coupled networks, which lack shared memory. Message-based sys

tems, on the other

hand,

incur a substantial run timeperformance_penalty, but

are more general inthat

they

canbe usedinawiderrange of configurations.

RevisionE

Version

1

(17)

The

(TDP)

- 8

-Section

1.2 Previous Work

Ada

rendezvous provides a

diplomatic

compromise between these two

environments. _Multiple tasks can access shared _variables, but in a restricted

way that allows for

loosely

coupled systems.

Updating

is guaranteed _only at

synchronization _points, so that shared variables can in fact reside in separate

memorieswithcopies passedbackandforth only

during

rendezvous."

[MUN]

TDP takes a similar approach and uses shared physical _{memory if} available and

aligned copies of_{memory in loosely-coupled} environments.

Taking

the_philosophy that

memory is only guaranteedtobe updatedat synchronization points allows the

flexibility

for efficient implementation ontightly-coupled machines without _{precluding implemen}

tationonloosely-coupledmachines.

Compatibility

betweentightly-coupledandloosely-coupledenvironments alsohas a

very important role for many multiprocessor systems. We often like to categorize a

machine as either tightly-coupled or _{loosely-coupled but in reality} multiprocessor sys

(18)

The Task

Distribution

Preprocessor

(TDP)

-

9

-Section

1.2 _{Previous Work}

"loose"

coupling

of processor groups. The

Butterfly

GP

1000

produced

by

BBN

Advanced

Computers

Inc. of

Cambridge

Massachusetts

is

a case in point [RUS].

Currently,

the

Butterfly

GP 1000 can have a maximum of 256 processors _sharing the

same physical memory.

Building

a configuration _comprising more than 256 processors

requires thatportionsofthe system communicate via a communication network. A sys

tem made _up of several

Butterfly

GP

1000 machines would

have

both tightly-coupled

components and a loosely-coupled component.

Ideally,

run time support for such a

configuration would make _crossing the loosely-coupled component invisible while still

allowing maximum _{efficiency in} the tightly-coupled environment.

Favoring

the

tightly-coupled environment for efficiency

is based

onthe assumptionthatwith more andmore

processors available in each _{tightly-coupled unit, there}will be fewerand fewer applica

tions that will require _crossing a loosely-coupled

boundary

to access _processing units.

Because applications will _{primarily function using}the tightly-coupled component ofthe

system,maximum_efficiency

is

targetedtothatenvironment.

Use of an unaltered

C

language as the source language forthe TDP system should

bring

maximum_portability and_utility to thesystem.

Hopefully,

_using apopular and well

RevisionE Version 1

(19)

(TDP)

10

-Section

1.2 Previous Work

supported

language like

C will allow TDP to _{be easily}

interfaced

to _existing applica

tions and code generators.

Going

with standard C as the

input

language,

a number of

parallel

implementations

oftheC language were exploredforpossibleuse as abasis for

TDP.

The first parallel C

implementation

considered is "Refined C"

implemented

by

Dietz & Klappholz [DIE2]. This

implementation

is based on concepts presented in an

earlier paper

by

the same authors

describing

_{how any} conventional sequential language

can be "refined" to provide parallel constructs [DIE1]. Dietz _{& Klappholz correctly}

identified

the three most difficult constructs to deal with in changing a sequential

language intoaparallellanguage:

'

'References

toglobaldata: sincethe_complexityof certainanalysis techniques

requires flow-analysis tobe localized to small regions ofa_program, the

flow-analysis is forced to make the "safe" assumption that _{every function} and sub

routine call might alter_everyglobal variable.

(20)

The Task

Distribution

Preprocessor

(TDP)

- 1 1

Section

1.2 Previous Work

References to

indexed

data structures: since it can be difficult to determine

which _element(s) of a data structure an indexed reference can _access, it may

again be necessary to assume that such a reference _potentially touches the

entire

structure."

[DIE2]

Refined

C

introduces aconstmct called a partition to replace global _memory and a

construct called an environment to _{specify limited} access to data. There are two major

reasons thatRefinedC wasnot chosen as a model. The first is thatelimination of global

memory and data structures as

they

are _normally presented in C programs is a major

change to the language.

Changing

C

dramatically

dilutes arguments for _using it in the

first place. Ifanon-standard source language is acceptable, then_using a

highly

expres

sivedistributed_programminglanguage like SR

[AND],

MML

[BOA]

orLinda

[AHU]

is

a more desired approach. The second problem with Refined C is that partitions are

implemented withtheuse of an addedlayerofindirectionfor referencing memory. Dou

ble indirectionto fetchdataisa valid approachfor heterogeneous distributed systemsbut

is

_{unacceptably inefficient for}programdistribution among homogeneoussystems.

(21)

The Task

Distribution

Preprocessor

(TDP)

- 12

-Section

The

Concurrent

C language presented

by

Gehani & Roome

[GEH]

was also dis

carded as a model becauseof extensive changesto the

C

language. This implementation

also had the added

disadvantage

of not _providing shared _{memory facilities.} In Con

current

C,

shared _{memory is left for} the C programmer to implement as described in a

quotefromthearticle

describing

thelanguage:

"Some final comments about shared_memory are inorder. First and

foremost,

we wantedConcurrent Cto allow (and _encourage)programmersto write port

able programs that will run _efficiently on multiprocessors with or without

shared memory. This

is

_why we choose a _{message-passing} _model, and _why

wehavenot added_{any language} constructsfor

dealing

withshared_memoryor

for simulating shared variablesinanon-shared_memory

environment."

[GEH]

Leaving

theimplementationof shared_memory_entirelyto theprogrammer and_encourag

ing

the use of a message _passing model for shared _{memory is} unacceptable for the

tightly-coupledmultiprocessorenvironmentstargetedfor TDP.

(22)

The Task

Distribution

Preprocessor

(TDP)

13

-Section

Although monitor accessto sharedvariablesprovidestheabstraction_{necessary for}mul

tipleprocess programs in

loosely-coupled

_{environments,} thislanguage implementation is

inefficient fortighdy-coupledsystems.

Always

_accessingglobal_memory throughamon

itorwill also

force

major_{restructuring in} sequential

C

programs that are to beconverted

tomultiple process programs.

Aparallel implementationoftheC languagepresented

by

Sonnenschein

[SON]

pro

vides shared _memory and synchronization with the use ofports and signals. Ports are

special global shared _memory that is referenced _{like any} other _{memory but} cannot be

referenced until _specifically assigned to a particular process. Signals are used to syn

chronize the _assigning of ports and special functions assign() and _release() are used to

gain or relinquish access to a port. Objections to this implementation are two fold. One

is that signals andports are implemented

by

_adding reserved words to the C language.

Although the change to the language is not as profound as Gehani & Roome 's Con

current

C

and Dietz & Klappholtz's Refined

C,

the language is changed to the degree

thata standard

C

compiler could notbeusedtocompile thesource code. Theother prob

lem is that there is no provision for more than one process to simultaneous access a

(23)

The Task

Distribution

Preprocessor

(TDP)

14

-Section

1.2 Previous Work

particular port memory. Shared memory is always of a restricted _nature, real-time

simultaneous accesstoshared_{memory is expressly}

forbidden.

Binding

[BIN]

presents a parallel

implementation

oftheC language that allowsthe

sharing ofall global_memorywithoutrestriction. The C

language

_{is essentially}unaltered

satisfying anothergoal for the TDPenvironment. In Binding'sparallel

C,

parallelism is

only simulated; all program tasksreside ina single UNIXprocess. Contextswitchesare

not

"preemptive";

a program must_explicitly relinquish control ofthe CPU

by

_calling a

"ContextSwitchO"

function. A similar implementation

by

Cormack

[COR]

allows

preemptive_{scheduling but}also simulates parallelism insidea singleUNIXprocess. Both

Binding's and Cormack's implementations provide a model _very close to what is pro

vided

by

"light"

processes or program

"threads"

[RUS]

provided

by

_manymultiproces

sor _operating systems. Programs _using the

Binding

or Cormack implementations could

be easily upgraded to utilize the

"light"

process primitives of_many ofthese multipro

(24)

The Task Distribution

Preprocessor

(TDP)

15

-Section

1.2 Previous Work

implementations

invisible

toanapplication, thatapplicationwill bemuch more portable

across_varying processor configurations.

Currently,

_{very few UNIX}

implementations

pro

vide "light" _processes;

therefore,

exclusive use of

them,

wouldimpactthe_portabilityof

the system severely. It is also hoped that the performance impact in the creation of

"heavy"

processes canbe

lessened

to_{be very} near theperformance impact forthecrea

tion of a program "thread" or "light" process.

However,

because the development of

"light"

processes in multiprocessor systems _{is very}

important,

_{nothing in} the design of

TDPwill preclude the use of threads in combination with TDPto achieve performance

and_{portability benefits in both}

loosely

and

tightly

coupled environments. The design of

TDPwillalso not preclude theuseofprogram"threads" toimplementtheTDPruntime

system if in the future threads become a standard feature of all UNLX and UNIX-like

operating systems and can provide parallelism and shared _memory across

loosely-coupled anduncoupled networked distributedsystems.

Due to the special goals for TDP that could not be satisfied

by

_any publishedver

sion of a parallel C

language,

TDP design went in a_completely new direction.

Adding

reserved words to the language to _specify parallel or remote functions reduces the

(25)

The Task

Distribution

Preprocessor

(TDP)

16

-Section 1.2 _{Previous Work}

portability ofthe source code and does not lendwellto conversion

between

single and

multiple process versions ofthe program.

Adding

_{reserved words would also eliminate}

the _possibility of

having

a single process version of a _program, compiled without

TDP,

using a standardC compiler.

Therefore,

to _specify _parallelism, TDPusesthe modulari

zation feature ofthe C language. The feature of separate module compilation is used

by

TDPtodefinewhat source codewillreside in separatetasks. Asingle source file defines

aprogramtask thatwill runas a separateUNIXprocess.

Using

the C preprocessor's #include

directive,

program modularization can be

achieved on several levels. Aprogram can use modularization forseparate compilation

and information

hiding

as _usual,

by

_separating source code into separate files. To build

the program _using

TDP,

"task" source modules can be created that _{have nothing but}

#include directives that gather together source modules that comprise a task. These

"task"

source modules are the source modules input to TDP. Because TDP runsthe C

preprocessoronall source modulesbeforeprocessing, the

"task"

(26)

TheTask

Distribution

Preprocessor

(TDP)

17

Section 1.2 Previous Work

Shared memory in TDP processed _programs, requires no specification

by

the user

because all static _{memory is} shared. All static _{memory is} also aligned sothat one _copy

of static _memory can be shared

by

all program processes without pointer conflicts.

Because TDP design is expressly aimed at tightly-coupled multiprocessor environments,

thisradicaldesigncanbeused withthebenefitofhigh efficiency forthe targetplatform.

RevisionE Version 1

(27)

The Task

Distribution

Preprocessor

(TDP)

18

-Section 2

PROGRAMMING OPTIONS

2

PROGRAMMING OPTIONS

2.1

Specifying

a

Task

Aprogrammerinforms TDP that certain

functions

are to bepart ofa separate pro

gramtask

by

_puttingthedeclarations forthese functions ina separateC source file. TDP

assumes that the code ineach C source file is code thatwill reside in a separate process

fortheprogram.

When converting single process C programs toTDP multiprocess programs, func

tions should be rearranged in the source files so those that can run in parallel are in

separate files. Because TDP runs the C preprocessoron all source files beforeprocess

(28)

The Task

Distribution Preprocessor

(TDP)

. 19.

Section

2.2

Specifying

Shared

Data

2.2

Specifying

Shared Data

All static _{memory in} aprogram except that which is declared in a

library

function,

willbe sharedbetweenprogramtasks.

Any

changestostatic_memorywill bereflectedin

all tasks. _{Not sharing}

library

function

static _memory allows the proper execution of

many standard UNLX

library

functions that are not designedto be re-entrant.

Any

data

declarations

preceded

by

the C reserved word

"static",

will also be shared but only the

task thatdeclared itwillhaveaccessto thelabel

describing

thedata.

String

data falls into

the same _category as local static memory. All string data is shared betweentasks. Be

causelocal static _memory and_{string data is} also aligned,pointers to this_memory can be

passedbetweentasks.

(29)

(TDP)

-20

-Section 2.3 Unshared

Memory

2.3 Unshared

Memory

To declare memory that is not _shared, a programmer must declare an automatic

variable or call _malloc() or _sbrk() to get

dynamically

allocated memory. Pointers to

unshared_memory cannotbesharedbetweenprogramtasks.

2.4 Stack

Memory

The stack_{memory for}eachtaskis not_shared, _any alterations to stack _memorywill

not be reflected in other tasks.

Therefore,

pointers to automatic variables must not be

(30)

The Task

Distribution

Preprocessor

(TDP)

₂₁

Section 2.5

Library

_Functions

2.5

Library

Functions

Library

functionsarelinked intoprogramtasksasthe_{last step in creating individual}

task modules.

Every library

function

that is used in the entire program is linked

into

EVERY task module whether a particulartask calls that function or not. This prevents

dataalignment problems caused

by

static _{memory declared inside} a

library

function. If

onetasklinked ina

library

functionthatdeclaredstatic_memory, and another taskdidnot

link in that

function,

the static _{memory may}

destroy

the _memory alignment ofthe two

tasks.

Static

_{memory declared in}

library

functions is the _only static _{memory in} a TDP

createdprogramthat is not shared. Not sharing

library

functionstatic _memoryallowsthe

proper execution of _many standard UNIX

library

functions that are not designed to be

re-entrant.

Revision

E

Version

1

(31)

The Task

Distribution

Preprocessor

(TDP)

- 22

-Section

2.6

Synchronizing

Tasks

2.6

Synchronizing

Tasks

When the user calls afunction that is defined in another source

file,

he/she is start

ing

aparallel task. The remote functioncall will return a child task descriptor and this

descriptor can be used to wait for the child task at _any point in the execution of the

(32)

The Task

Distribution Preprocessor

(TDP)

. 23

-Section 2.6

Synchronizing

Tasks

funcl()

{

int child_descr; intretval;

child_descr=

func2();

parallel code

retval=

TDPwait(child_descr);

}

funcl()

and

func2()

are defined in separate source files andthe code betweenthe call to

func2()

and

TDPwait(),

is code thatwillbeexecuted inparallel withthecode in func2().

Thereturn value of

func2()

isreturnedfrom TDPwait().

TDPwait()

is identical to the

ab-sorb() function in the parallel

C

implementation presented

by

Cormack [COR]. The

childdescriptor is avalue thatis uniqueto aparticular call and_{is different for every} call

evenifmultiplecalls are made to thesamefunction.

If

by

the time

TDPwait()

is called, the child task _{has already}

terminated,

then

TDPwait()

simply returns thevalue returned

by

theremote function. Ifthe child task is

still _running when

TDPwaitQ

is called, the parenttask will be suspended until thechild

(33)

The Task

Distribution

Preprocessor

(TDP)

₂₄

-Section 2.6

Synchronizing

Tasks

task terminates. The call to

TDPwait()

can beanywhere intheparent task andit isnot

necessary to call

TDPwait()

at all.

There is nothing

in the TDP platform that requires

thata parent taskwait for

its

children.

Children

canterminate

long

aftertheirprogenitors

haveterminated.

2.7

Building

As

A

Single Task

An application that uses the

TDPwait()

function can be built and ran without TDP

by

simply creating a function called

TDPwait()

that returns its argument. The return

value of a function would _{simply be} passed through the

TDPwait()

function unaltered.

This may be usefulifthereis a suspected

bug

intheparallelconstructs of a programorif

it is

desiredto use a debugger that can _{only function} on a single process version of the

(34)

The Task

Distribution Preprocessor

(TDP)

-

25

-Section 2.8

Second

Level

Modularity

Conflicts

2.8 Second Level

Modularity

Conflicts

It

is

expected that some programmerswill define TDPtasks

by

_{simply creating files}

thatinclude groups offiles for aprogram_usingtheCpreprocessor#include directive. If

aprogram sourcefile is normally compiled_{separately but is}nowmergedwithother

files,

anumber ofconflicts can arise:

1)

Two source modules that are _normally compiled _{separately may have} a vari

able with the same name declared with the keyword "static" outside of a

function_{definition (therefore giving it}scopefortheentire source file). Ifthese

two source filesweremerged together,thevariable wouldbe multiply defined.

TDPsolvesthisproblem whenitrenames all variablesdeclared withthe "stat

ic"

keyword. Each declarationofthestatic variable wouldbe givena separate

newnamewhenmovedto theglobaldata

file,

thereby

_resolving theconflict.

(35)

(TDP)

- 26

-Section

2.8

Second

Level

Modularity

Conflicts

2)

The scope of afunctionnamecanalsobe restrictedto a single source _{file using}

the "static" keyword when the function is declared. It is possible that two

source

files

_may use the same "static" _function name and ifthe two source

files were merged the functionwould_{be multiply defined. TDP} will generate

an errormessage and terminate _{processing if}this problem occurs. It _{is up} to

the programmer to choose a separate name for _multiply defined functions in

thissituation.

3)

Each source module that_{is normally}compiled _separately willhave its own set

of#include statementsforstructuredefinitions and manifest constants. Ifthese

source files are thenmerged with_{others, many}#include statements willbe du

plicated. TDP defines the manifest constant

"TDP"

sowhen there aremulti

ple #include statements

they

can be surrounded

by

conditional preprocessor

directives:

(36)

(TDP)

- 27 -Section2.8

Second

Level

Modularity

Conflicts

4)

A manifest constant can

be

given one value inone source

file

and a different

value in another. Ifthe two

files

are merged there_{may be} aconflict. Some C

preprocessors allow redefinition of amanifest constant, but for those that do

not, aprogrammer shoulduse the#undefpreprocessordirective attheend ofa

sourcefile formanifestconstantsthat_may conflict.

R "

'nn F Version 1

(37)

TheTask Distribution

Preprocessor

(TDP)

28

-Section

2.9

Other Synchronization Constructs

2.9 Other

Synchronization

Constructs

TDPwait()

is the _{only TDP function} provided to synchronize parallel tasks. If a

programmer needs more elaborate communicationorsynchronization between tasks, the

entire UNIX C

library

is

at the programmer's disposal. Because TDPprocesses are true

UNIX_processes, _{any UNIX} system callthat can be usedto synchronize separate UNLX

processes canbeusedtosynchronize TDPtasks. TDPreservesfor its own_use, _only one

message queue identifier and one signal. BothTDP's message queue identifierand _sig

nal numbercan bechanged

by

the usertoeliminate conflict with theiruse ina particular

(38)

The Task

Distribution

Preprocessor

(TDP)

Section

3

-29-PROCESSOR SPECIFICATION

3

PROCESSOR

SPECIFICATION

3.1 TDP

Processing

Diagrams

Figure

3-1 Program

Load Module Creation

without

TDP

(39)

The Task

Distribution

Preprocessor

(TDP)

Section 3.1

30-TDP

Processing

Diagrams

Figure 3-2 Multiple Load Module

Creation

Using

TDP

(40)

TheTask Distribution Preprocessor

(TDP)

. 3 1

Section 3.1 _TDP

Processing

Diagrams

3.2 TDP

Processing

Description

TDP accepts as

input,

all the C source files that comprise a program. TDP will

assume that each source file is to be a program task. A program task process will be

started whenever one of the functions defined in the

task,

is called

by

a function in

anothertask.

TDP processes the source files in two passes. Before the first pass, all the source

code isprocessed

by

the Cpreprocessor (cpp). TDP processing inpass oneproceeds in

the

following

manner:

o If TDP encounters afunction declaration in asource

file,

thefunction name and its

arguments are savedinalinked list for later reference. Thename ofthe fileandthe

numberofthefunction declaration isalso storedfor laterreference.

Revision

E Version 1

(41)

(TDP)

32

-Section 3.2 TDP

Processing

Description

o If TDP encounters a _string _constant, the _string

is

saved in a linked list to be later

usedtoinitialize an_arraythatwillcontain thedata forallstringsintheprogram.

o If the C reserved word "static" is encountered, TDP saves the declaration to be

usedlater in a globaldeclarationthatwillreplace thestatic variabledeclared.

When all theprogram's source files have been_read, TDPoutputs an _{array declara}

tionthatwillreplace all the_string constants encountered intheprogram. The stringcon

stants in theprogram will be replaced

by

offsets into this _string array. Declarations are

also generated for variables that will be used to replace the static variables in the pro

gram. Uniquenames are chosenforall static variables _simply

by

_appending thevalue of

a counterto aunique string. The declarations are all outputto the singleTDPgenerated

globaldata file.

(42)

(TDP)

. 33

-Section3.2 TDP

Processing

Description

o If aglobal declaration

is

_encountered, it

is

appended to the single data file for the

program. Ifthe declaration

does

not have an

initializer,

it is givenone. Initializers

are giventoprevent misalignmentthatwouldoccur when uninitialized static data is

put intheBSSsectionof memory.

o Ifalocal static variable declaration is_encountered, a "#define oldname

newname"

is appended to the task output file. The "oldname" is the original identifiername

in the task input file and the "newname" is the replacement name given to the

static variable inpass one. When the end ofthe current block is encountered, (i.e

theendofthe scopeofthe_variable) a "#undef

oldname"

is appended to theoutput

file.

o Ifa_string constantis encountered, itis replaced withapointer offsetinto the _string

array that was put into the global data file after pass 1. The correct offset into the

string array forthisstringconstant was calculatedinpass 1.

o When a function call is encountered, TDP looks to see ifthe function declaration

(43)

(TDP)

- 34

-Section 3.2 TDP

Processing

Description

was encountered in pass 1. Ifthe

function

call

is

not

defined

in the_program, the

function name is put inthe list of

library

routine calls fortheprogram. Ifthe func

tion call was defined but in a _{different task,} the function name is put in a list of

remotefunctioncallsforthe task. Theremotefunctioncall isreplacedinthesource

file

with a callto a special TDPfunctionthat

initiates

a remotecall _using the origi

nal function call arguments andthe functionnumber. The functionnumberforthis

functionwas assignedinpass 1 whenthefunction declarationwas encountered. No

information

is

saved for functions that are called anddefined inthe same

task;

this

code willjust make anormallocal call. The code for alocal call is just echoed to

theoutputfile.

o Ifthefunction main()is encountered ina source

file,

TDPrenamesthefunction and

records the fact the current task is the _startup task forthe program. At the end of

this

function,

TDPwill output acall to a special

TDPexit()

function that allows the

(44)

The Task

Distribution

Preprocessor

(TDP)

. 35.

Section 3.2 _TDP

Processing

_Description

o Allcode not mentioned _above, iscopied

directly

fromthe theinput source

file

to the

taskoutput file.

Ina separate

file,

TDP generates adeclaration for a global structurethatcontainsall

information aboutthe functions defined intheprogram. Thisstructure is initializedwith

the taskname, function name, functionpointer and thesize offunction arguments. The

functionnumber

is

anindex intothis_arrayoffunction structures.

TDP also generates a single global structurethatcontains allthe_necessary runtime

information about the program and about each particular task. This structure also con

tains apointerto alinked listthatdescribes eachinstance ofafunction callfora particu

lartask.

Both the function list and the run time global structure are kept in private static

memory.

Every

task has

its

own _copy ofthese structures,

they

are not shared between

tasks.

(45)

The Task

(TDP)

36

-Section 3.2 TDP

Processing

Description

3.3 Processor Design

The TDP parser/code generator has a _main() function that contains two loops that

operate on all the

files

onthe command line. The first

loop

is pass one oftheprocessor

andthesecondispasstwo.

The scanner used

by

TDPis created _usingthe UNIX_utility lex. It has thecapabil

ity

to scan all C declarations and calls a numberof specialfunctions for parsing and out

put. The samescanneris usedfor bothpassoneand passtwooftheprocessor.

TDP parsingand output routines manipulatetwolinked lists. One linked listisused

(46)

The Task

Distribution

Preprocessor

(TDP)

37

-Section 3.4

Achieving

_Data

Alignment

3.4

Achieving

Data Alignment

Toprovide shared_memory

functionality,

TDPaligns global _{memory in}all tasks so

that it can be accurately copiedfromtask to task without _{relocating memory}references.

TDPputs all thestatic data declared in aprogram intoa single source fileandcreatesthe

load modules for each task in such a_way as to give the static data identical virtual ad

dresses inallthe loadmodules fortheprogram. Datacanbe

directly

copiedbetweenthe

tasksin theprogram because all tasks operate on identicalcopies ofthe data. More im

portantly, shared physical _memory is feasible because pointer values stored _{in memory}

arevalidforall processes intheprogram.

To accomplish _memory alignment there are some general characteristics ofUNLX

linker/loaders

upon whichTDP relies. When aUNIXlinker/loaderallocates_{memory for}

a program load module, the addresses assigned to code and data objects are virtual

(47)

(TDP)

3g

. Section3.4

Achieving

Data Alignment

addresses. When memory is accessed

by

aprogram at run

time,

thevirtual pointer to a

variable

is

remappedtoa physical

memory

address.

TDPputs all static data

declarations

into asingleC source file for a program. This

source file is compiled and the object module _{is linked into every} program task. This

assures that all static

data

will be placed in a single block of_memory space in all pro

grams. This block of

"memory

space"

or

"section",

is not guaranteed to start at the

same address in all theprogramtasks.

Typically

thelinker/loaderwill putthis datasec

tion after the code section in virtual memory. The exact placement ofthe data section

variesfromsystemtosystembutwill always_{partially depend}onthesize ofthe code sec

tion. Thismeans

that,

althoughthe dataobjects are the samedistance fromeachotherin

each

task,

the addresses are still different in everytask

depending

onthesize ofthecode

sectionforthat task. To achievedataalignment, thevirtual addresses ofthedatamustbe

shifted sothat the virtual address ofthestartofdataobjectsisthesame inalltasks. TDP

(48)

(TDP)

39

.

Section3.4

Achieving

Data Alignment

in the

data

section equal to the

difference between

the

starting

address ofthe module

with that largest data section start address and the start address of the current load

module's

data

section. This

hole

inthedatasection shiftstheaddressesforthestaticdata

inthe taskloadmodules sothat

they

allbeginatthesamelocation.

The UNIX System V Release 3.0 Programmer's Guide givesacomplete description

ofhow to manipulate

load

modules _using the Link Editor Command Language for the

linker/loader: Id. An iftle is afilewhichcontains LinkEditor Command Languagecom

mands to manipulate load modules. The

following

is the default ifile run

by

Id when

executed on anIntel 80386 System V Release 3.X UNIXsystem:

RevisionE Version 1

(49)

TheTask

Distribution

Preprocessor

(TDP)

. 49.

Section 3.4

Achieving

Data Alignment

SECTIONS

.text

OxdO

:

{ *(.init)

*(.text)

*(.fini) }

GROUP

BIND( NEXT(0x3ff000)

+

((SIZEOF(.text)

+

ADDR(.text))

_%

0x2000))

{

.data:

{ }

.bss :

{ }

Mostofthedetail in the code above is unimportantto this discussion but is included for

completeness. _{The meaning} of each construct is explained in the UNIX System V

Programmer's Guide [UNI]. The

following

ifile is an example of one that was usedto

build

one oftheload modules in aTDPprocessed program. Noticethatit is identical to

the

default

specification except for the increment value placed in the .data section

(50)

TheTask

Distribution

Preprocessor

(TDP)

. 41 .

Section 3.4

Achieving

Data

Alignment

SECTIONS

(

.textOxdO:

{ *(.init) *(.text) *(.fini) }

GROUP

BIND(

NEXT(0x3ff000)

+

((SIZEOF(.text)

+

ADDR(.text))

%

0x2000))

{

.data:

{

.+=0x318;

}

.bss :

{ }

Inthisparticular case, the "hole" inthe data section is 318

(hex)

bytes in length. This

increment

command will cause Id to start _{allocating data for declarations} after _skipping

318

(hex)

bytes.

By looking

atthis ifile we can surmise that there is aloadmodule for

this programthat has adata section with a start address that is 318

(hex)

largerthan this

load

module'sdatasection start address.

Ifalink/loader onaparticular systemdoesnot provide a means for putting ahole in

Revision

E Version 1

(51)

The Task DistributionPreprocessor

(TDP)

- 42

-Section 3.4

Achieving

DataAlignment

the data _section, TDP will generate a

dummy

declaration

equal to the sizethat thehole

wouldbe. The declaration ismade sothatit isthefirst dataallocated

by

thelinker/loader

(52)

(TDP)

-

43

-Section 4

RUNTIME

_PLATFORM

4 RUNTIME

PLATFORM

Simply

aligning data is not all there

is

to the story, TDP must also provide an

efficientmeans fortask_spawning and synchronization. A

library

of runtime routines is

linked into all TDP processed program tasks. The TDP

library

serves to manage all

aspects oftheTDPrun timeenvironment. The only visibleevidenceto the userthat this

library

isused,are calls that he/shemakesto the

TDPwait()

functionthat allows aparent

task towaitforachildtask.

P . .

p Version 1

(53)

The Task

Distribution

Preprocessor

(TDP)

. 44.

Section 4. 1

Runtime Description

4.1

Runtime Description

TDPgenerates a programthat runsin the

following

manner:

o To start a _program, the user starts the fork server. The fork server does a

fork()

exec() to start the first

task,

then waits on amessage queue. A UNIXmessage is

sent to the fork server whenever a task calls a function in another task. Upon re

ceipt of the _message, the fork server executes a

fork()

_exec() _according to the

specificationsinthe message.

Therefore,

thefork server istheprocess parent of all

program processes.

0 _{Upon startup}ofthe firsttaskinthe system,anynecessary initialization isperformed

andtheprogram's originalmain()function(now renamed)is executed.

(54)

The

Task

Distribution

Preprocessor

(TDP)

-

45

-Section

4.1 _{Runtime Description}

o Ifa

library

function

_is

called, again, nothing unusual occurs; the task's_copy ofthe

function

is executedinthesame _wayasina single processprogram.

o If a program

function

is called that is defined in another _task, the

following

sequenceisperformed:

1)

A special TDP function is called. TDP hasplaced a callin theprogram code

that appearsasfollows:

TDPcall(funcnum,arguments,

. . _.);

The funcnum is aconstantinteger representingthefunctionnumbercalculated

by

TDP. The arguments are the exact arguments placed

by

the user for this

function call in the original source code.

During

_{preprocessing,} TDP has

replacedtheoriginaltextofthecall:

func(

with:

TDPcall(funcnum,

The TDPcallfunction is declared_usingthe variable parameter macros defined

by

the UNLX System V macro package varargs (see the UNIX System V

Programmer'sReferencemanual foracompletedescriptionofthesemacros):

RevisionE Version 1

(55)

The Task

Distribution

Preprocessor

(TDP)

- 46

-Section

4.1 Runtime Description

TDPcall(va_alist)

va_dcl

{

va_list_pvar;

int

funcnum;

va_start(pvar);

funcnum=

va_arg(pvar);

The variable "funcnum" will be an index into the function list structure

placed

(by TDP)

intotheglobal data file.

2)

TDPcall()

creates a_stringtobe sentina messageto theforkserver. _{The string}

will contain the target task _name, the called function _number, the instance

number ofthefunctioncall, thecurrentprocessid_number, andthenameofthe

shareddata file.

(56)

The Task

Distribution

Preprocessor

(TDP)

-

47

-Section

describing

all functions declared intheprogram. The function list'svaluefor

the number of words for arguments

in

a particular

function,

was determined

when the function declaration was parsed

during

program building. The fol

lowing

code is executed in

TDPcall()

to _copy the function arguments into the

message

(Again,

a variable number of function arguments is extracted _using

varargs):

for

(i=0;

i<

TDP.funclist[funcnum].numarg_words;

i++

)

message.args[i] =

va_arg(pvar,int);

The variable

"TDP"

is the global structure that references all TDP run time

structures. The structure member

"funclist"

is the structure that contains

information

describing

each remote function. The structure member

"numarg_words"

is the number of_memory words needed to contain all the

function arguments for a particular function. The variable

"funcnum" was

assignedin step 1 withthe first argumenttoTDPcall(). The function va_arg()

is

the varargs macro that allowsextraction ofavariable number of arguments

inafunctioncall.

(57)

The Task

Distribution

Preprocessor

(TDP)

- 48

-Section

4)

TDPcall()

copies all shared datato a

temporary

fileor arranges forattachment

of shared physical memory, (attachment of shared physical _{memory is} not

implemented in TDP Version 1.0).

TDPcall()

thensendsthemessage contain

ing

the taskparameters andfunctionarguments to theforkserver.

5)

After sending the UNIX message to the fork _server,

TDPcall()

returns achild

processdescriptorto thecaller. Thechildprocessdescriptoris usedlateras an

argument to the

TDPwait()

function. The callto

TDPwait()

allows theparent

(58)

The Task

Distribution

Preprocessor

(TDP)

Section

4. 1

-49-RuntimeDescription

6)

Upon receipt of a UNLX message, the fork server executes a

forkQ

and the

parentforkserver process waits again onthemessagequeue.

Figure 4-1 Communication

with

the

Fork Server

Task Name Function Number

Instance Number ParentTask's PID Shared

Memory

Description

FunctionArguments

forkQ

RevisionE

Section4

(59)

The Task

Distribution

Preprocessor

(TDP)

Section

4. 1

50-Runtime Description

7)

The child oftheforkserversends a message _containing thefunctionarguments

toitself (to a processwith itsownprocess id). Thechildfork serverthenexe

cutes an_execQ, _passingthe _{string in}theUNIXmessage to theexecQ function.

The child ofthe fork serverhas now "become" the childtask (sameprocess

id). The childtask's main()function receives thefunction arguments sent in a

messagebeforetheexec().

Figure

4-2 Creation

of

Child

Task

msgsndQ

Child Task

msgrcvQ

(60)

The

Task Distribution

Preprocessor

(TDP)

Section 4.1

51-Runtime Description

8)

The TDP generated _main() function in the child task has access to the four

arguments passed on the command line. The

function

number, function call

instance number, and parent task's process id are the first three arguments.

The

temporary

_{file containing} the shared data (orthe shared _memory

descrip

tion)

is

the last argument. The child task copies in shared _{memory from} the

temporary

file created

by

the parent task (or attaches to shared physical

memory).

Figure

4-3

Tightly-Coupled Configuration

Revision E

Section

4

Version 1

(61)

The Task Distribution

Preprocessor

(TDP)

- 52

-Section

4. 1

Runtime

_Description

9)

The task's main() function thenpushes the

function's

arguments on the stack

and callsthefunctionspecifiedinthe firstcommandlineargument. The length

of the arguments for this particular function is obtained from the TDP gen

erated function liststructure.

10)

After function execution, the main() routine calls a function that will _copy

shared _memory to another

temporary

file for return to the parent task. If

shared physical _{memory is} _{used, the} child task _{simply detaches from} this

memory.

11)

Afterthe shareddata is copied backto a

temporary

file,

the_main() functionof

the child task sends a UNIXmessage to the parent task. The child task also

sends asignalto theparenttask_using the

kill()

UNIXfunction. Theprocess id

ofthe parent _task, _necessary for sendingtheparent the message and _signal, is

(62)

(TDP)

Section

4.1

-53-Runtime Description

nal. Ifnoverification _{comes, the}childtaskagain sends a signalto theparent.

The parent couldhave missed theoriginal signal forvarious _reasons, the most

likely

being

thatitwas

busy

_processingthereturn of anotherchildtask.

Figure 4-4

Child

Task Termination

msgrcv()

Function Number

InstanceNumber

Child Task's PID Function'sReturnValue

msgsnd()

12)

All taskshave asignal

handling

functionassignedtohandle theterminationof

childtasks. When thechildtasksendstheparentthetermination signal, UNLX

will branch the parent task to the signal

handling

function. The signal

han-RevisionE Section 4

Version 1

(63)

The Task

Distribution

Preprocessor

(TDP)

. 54.

Section

4. 1

Runtime Description

dling

function

in the parent task will

look

on the TDP message queue

for

messages with a type equal to

its

process id. The

UNIX

message explains

whichfunction has

terminated, its instance

number, theprocess id ofthechild

task,

thereturn value ofthe

function

and thename ofthe

temporary

files

con

taining

the shared datatobe copied back to theparent. Theparenttasks sends

a signal backtothe child

(using

theprocess id inthemessage)notifying itthat

the message has been received.

Receiving

this response signal will cause the

childtoexit normally.

13)

The parent taskcompares the bytes inthe original shared data file sent to the

child

task,

and the altered shared data file returned

by

thechild. Ifabyte has

changed, it is copied back to the parent tasks address space. _{This processing}

does not take place if shared physical _{memory is}

being

used between tasks

(attachment of shared physical _{memory is} not implemented in TDP Version

(64)

(TDP)

- 55

-Section4.1 Runtime Description

suspended in

TDPwait(),

_waiting for this function call to return, the

TDPwait()

functionreturns withthereturn value ofthe function. Iftheparent

hasnot yet called

TDPwait()

forthiscall

instance,

thereturn value ofthefunc

tion call is saved andwill be returned

by

TDPwait()

whenit is called forthis

callinstance.

. .

P Version 1

Revision n

RUNTIME PLATFORM

(65)

(TDP)

Section 4.2

-56-Runtime Diagrams

4.2

Runtime

Diagrams

The

following

diagram summarizes the processes and communicationinvolved in a

remote functioncall whenphysical shared_{memory is}notpossible:

Figure 4-5 Loosely-Coupled Run Time System

msgrcvQ

FunctionNumber InstanceNumber Child Task's PID Function's Return Value

Shared

Data File Name Returned Data File Name

Task Name Function Number

Instance Number Parent Task's PID Shared Data File Name

FunctionArguments

Parent Task

Child Task

msgsndO

kill()

msgrcvQ

msgsnd()

(66)

TheTask DistributionPreprocessor

(TDP)

Section 4.2

-57 Runtime Diagrams

The

following

diagramsummarizestheprocesses and communication involved

inaremotefunctioncall whenit ispossibletosharephysicalmemory:

Figure 4-6

Tightly-Coupled

Run

Time

System

msgrcvQ

TaskName FunctionNumber

Instance Number Parent Task's PID Shared

Memory

Description

FunctionArguments

Function Number Instance Number

Child Task's PID

Function's ReturnValue

msgsndQ

killQ

Function

Arguments

Revision E Section 4

Version 1

(67)

The Task

Distribution

Preprocessor

(TDP)

. 5g .

Section 4.2

Runtime Diagrams

4.3

TDP

Runtime

Library

The TDPruntime

library

is linked into

allprogramtasks. The

library

provides

all code _necessary tomanage parallelism inthe

C

_{language. The only}visible inter

face to this

library

in the user's source code are calls to

TDPwaitQ

to synchronize

paralleltasks.

The call to

TDPwaitQ

can _{be easily "stubbed} out"

by

the user when TDP is

not used to build the program. A sequential version ofthe user's program can be

built

by

_{just providing}afunctioncalled

TDPwaitQ

thatreturnsthe argumentpassed

to it. In this manner, a programmer can _easily switch back and forth between

sequential and parallelimplementationsofaprogram when_{necessary for}

debugging

purposes.

(68)

The Task

Distribution

Preprocessor

(TDP)

.

59

.

Section4.3 _{TDP Runtime}

Library

visible. A call to

TDPcallQ

is made wherever the program calls a remote pro

cedure and

TDPusrexitQ

is called whereverthe userhasspecifieda call toexit(). At

theendofthe user's_main() function TDPwill also place acallto

TDPexitQ

which

will_{properly notify}theforkserver oftheterminationoftheuser's mainfunction.

As well as specific calls placed in the user's source _code, TDPalso links in a

number of routines used

by

these calls. Each task is also provided a_main() func

tion thatplaystheexecutive roll in setting upthe stackforaprocedure call, execut

ing

acallrequest, and _receiving and_returningshareddatatoa parenttask.

Rpvic'on F Version 1

(69)

The Task

(TDP)

. go

-Section 5

VERIFICATION

AND VALIDATION

5 VERIFICATION AND

VALIDATION

The important elementsofTDPthatshouldbe testedare thecapabilities ofthe

scanner/parser andthe correctness oftheruntimeenvironment. The capabilities of

the parser can be tested

by

_processing a program that contains all possible C data

declaration syntax. Allpossible function declaration

types,

local static declarations

and function call syntax should also be tested. Code or data that is not used in a

runningprogrammustbe_visuallyverified.

The run time environment can be tested on aprogram

by

program basis. A

program's results when run after_processing

by

TDP should be identical toresults

obtainedwhentheprogramisnot processed

by

TDP. The only exceptionto _{this, is}

that parallelism in aprogram that affects output will _{only be}visible in aTDPpro

(70)

(TDP)

- 61

-Section 5 VERIFICATIONAND VALIDATION

tasks. Parallelism is demonstrated

by

therandom

interleaving

oftheoutput.

Version 1 Revision E

(71)