HP Fortran Programmer Guide (766160-001, March 2014)

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