Now run the second program in the second process:

$ wake_up

At this point, the program executing in the first process outputs the following and completes execution:

I'm up!

The following command line confirms that the shared memory segment was released:

$ ipcs -m

 

IPC status from /dev/kmem as of

Fri Mar 21 15:55:29 1997

T ID KEY MODE OWNER GROUP

 

Shared Memory:

 

m 0

0x4119c72b --rw-rw-rw- root

root

m 1

0x4e180002 --rw-rw-rw- root

root

m 2

0x41187bf4 --rw-rw-rw- root

root

m 3

0x00000000 --rw------- root

sys

m 7004 0x43186ea0 --rw-rw-rw- daemon daemon

For information about sharing data between Fortran program units and C functions within the same program, see “Sharing data” (page 122). The HP Fortran Programmer's Reference provides detailed information about the COMMONstatement and about the $HP$ SHARED_COMMONdirective. Refer to the shmop(2) man page for information about HP-UX shared memory operations.

Modules vs. common blocks

The common block has been a mainstay of Fortran programs throughout the evolution of the language, and it continues to be a part of Fortran. The common block provides a convenient means to share data among program units, especially when the program units sharing data do not otherwise communicate with each other. The common block can also be used to share data between simultaneously executing Fortran programs (see “Sharing data among programs” (page 72)) and between Fortran program units and C functions linked together in the same program (see “Sharing data” (page 122)).

One of the problems with the common block, however, is that the programmer must replicate the COMMONdeclaration in each of the sharing program units. If any of the common variables are out of order or have a different type or size, the program units may not access the same data. The compiler gives no indication of this discrepancy because it assumes that the programmer is giving one program unit a different view of the shared storage—even when the discrepancy is owing to oversight.

To deal with this problem, many implementations of FORTRAN 77 have provided the

INCLUDEextension. This extension enables the user to centralize common block definitions in one file. At compile-time, the compiler reads the file into program units that have the INCLUDEI line. While this approach eliminates the problem of discrepant common blocks, it introduces another problem: the INCLUDEfacility is nonstandard FORTRAN 77, and its use is nonportable.

To deal with the portability issue, Standard Fortran defines the INCLUDEline. Unfortunately, the definition in the Standard leaves many of the details up to the implementation, so that use of the INCLUDEline in Fortran programs still runs the risk of nonportability.

Another problem with the common block—especially when used with equivalencing—is that it can inhibit optimization. Common block variables are generally ineligible for register allocation, and aliasing variables in common can prevent the optimization of the program units that use the aliased variables.

The module program unit is the Fortran answer to the common block. The programmer declares shareable variables in a module. Any program unit that wants to access them references the name of the module in a USEstatement. The concept of the module eliminates the need to re-declare the common variables, without requiring the INCLUDEline.

74 Controlling data storage

Page 74
Image 74
HP UX Fortran Software manual Modules vs. common blocks, $ wakeup, Im up