(j3.2006) Another application for coroutines

Van Snyder Van.Snyder
Fri Jan 29 16:17:21 EST 2010

During the 2008 requirements phase, I advocated coroutines to ease
"reverse communication" in library codes that need access to user code.

I've recently encountered another circumstance where a coroutine would
be helpful.

The program of my current responsibility integrates the radiative
transfer equation through the limb of the Earth's atmosphere, from space
to our instrument.  The instrument's antenna points at about 70 angles
over a period of about 26 seconds.  Therefore, each path through the
atmosphere is of a different length.

The procedure that does the integration has about three dozen arrays
with at least one dimension that depends upon the path length, and upon
the discretization of the path (which is determined by input data).

To avoid a trip to the allocator (and deallocator) for each pointing, we
allocate these arrays once for each scan, for the path of longest
length, as automatic arrays.

For a variety of reasons, only a few having to do with these arrays,
this subroutine has become enormous (3784 lines).  I'd like to break it
up.  So as not to add three dozen arrays to an already-long calling
sequence, I'd like to continue to access them either locally or through
host association.

An obvious way to handle this is to convert them from automatic to
allocatable, either put them in a module or make them save variables,
and add the appropriate explicit allocations and deallocations.  This
risks failing to deallocate a new one someday, if I have to add one
(which I've had to do several times).

One advantage of automatic variables, compared to allocatable ones, is
that you can't forget to deallocate them (which I would have to do to
get rid of them if they're save variables).  Another potential advantage
is that the processor might make one trip to the allocator to get them
all in one gulp, then calculate its descriptors.  I don't know whether
this actually would be an advantage, or if so whether any processor
exploits it.

If these variables were automatic variables in a coroutine, It could be
called to get them created and to do some preliminary calculations
necessary for all paths.  Then it would suspend instead of returning,
thereby preserving its activation record.  It would be resumed for each
path, and would finally return after the last path, at which time the
arrays would be deallocated.

More information about the J3 mailing list