Go to the bottom of this page. See the search engine and sub-section links.
Go to next page Go to previous page Go to top of this section Go to top page Go to table of contents

Previous Section Headers

User's Guide to NCAR CCM3.6 Search Page


3. CCM3.6 Internals
    3.4 Multitasking Strategy
        3.4.1 Shared-Memory Multitasking


3.4.1.1 Shared-Memory Management

stack-based memory management scheme was crucial in designing a shared-memory multitasked version of CCM3.6. When a local variable is allocated on the stack, its lifetime is limited to the time the subroutine or function in which it is declared is active.  Hence, stack-based local memory allocation makes for more efficient memory usage since memory is allocated to each routine only when required.

Multitasking is another important consideration in using stack-based memory allocation.  Unlike static memory, stack memory declared within multitasked regions of code is automatically replicated across processes. Thus, use of the stack is the only reasonable way to ensure that multitasked routines are "reentrant," i.e., they may be entered by more than one processor at once without violating previously defined data space. For example, consider array pmid declared locally in subroutine linemsbc. Array pmid is dimensioned (plond,plev) with no latitude index because each instance of linemsbc, by virtue of its execution on a separate processor, has its own local copy of the array. The routine can therefore freely modify the contents of pmid without interfering with other concurrent instances of linemsbc.

There are a few places where locally defined memory is statically allocated within a multitasked region of the code. This is done for some read-only memory mainly to avoid having to reset certain variables every time a routine is invoked. These variables may be declared static via a Fortran save statement, or by virtue of appearing in a data statement. One disadvantage to running the model on multiple processors is that memory usage is increased as compared to a single-threaded run. The primary culprit is the stack memory replication across processors just discussed.


 Go to the top of this page. See links to previous section headers.
Go to next page Go to previous page Go to top of this section Go to top page Go to table of contents

 Search for keywords in the CCM3.6 Users GuideSearch page

Questions on these pages can be sent to... erik@ucar.edu .


$Name: ccm3_6_6_latest2 $ $Revision: 1.34.2.1 $ $Date: 1999/03/25 21:38:36 $ $Author: erik $