Browse Prior Art Database

Use of scoped objects to manage cleanup and recovery of transient resources

IP.com Disclosure Number: IPCOM000014316D
Original Publication Date: 2000-Apr-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 5 page(s) / 57K

Publishing Venue

IBM

Abstract

Disclosed is a method for managing cleanup and recovery of transient resources in a computer program written in a stack-based, object-oriented programming language. In such programming languages, stack allocated objects are 'garbage collected' automatically when those objects leave the current scope of execution. When an object is garbage collected, its 'destructor' is executed. A method is described which exploits this feature to provide a unified mechanism which manages the cleanup and recovery of transient resources (for example, heap-allocated storage, locks) when execution scope ends normally or abnormally. To allow computer programs to operate correctly in the presence of failures, computer programmers include additional program code in their programs to recognize and react to unexpected error conditions. In a programming language such as C++, for example, unexpected error conditions manifest themselves as exceptions or signals . Exceptions are caught and handled by enclosing a block of code within a try/catch statement, whereas signals are caught and handled by coding a signal handler. Although try/catch blocks and signal handlers are coded as separate entities, they often perform similar duties. For example, after an unexpected exception or signal, a program may wish to free a held lock or release allocated heap storage before terminating. Throughout the remaining discussion, it is assumed that the destructor for stack allocated objects is given control for unexpected error conditions such as unhandled exceptions and signals. A mechanism is described here which unifies cleanup and recovery processing by executing such code within a destructor of a specially designated, stack allocated object called a recovery object . For each execution scope for which protection (i.e., cleanup and/or recovery) is desired, a recovery object is declared on the stack. The recovery object is defined as follows: Data

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 5

Use of scoped objects to manage cleanup and recovery of transient resources

  Disclosed is a method for managing cleanup and recovery of transient resources in a computer program written in a stack-based, object-oriented programming language. In such programming languages, stack allocated objects are 'garbage collected' automatically when those objects leave the current scope of execution. When an object is garbage collected, its 'destructor' is executed. A method is described which exploits this feature to provide a unified mechanism which manages the cleanup and recovery of transient resources (for example, heap-allocated storage, locks) when execution scope ends normally or abnormally.

To allow computer programs to operate correctly in the presence of failures, computer programmers include additional program code in their programs to recognize and react to unexpected error conditions. In a programming language such as C++, for example, unexpected error conditions manifest themselves as exceptions or signals. Exceptions are caught and handled by enclosing a block of code within a try/catch statement, whereas signals are caught and handled by coding a signal handler. Although try/catch blocks and signal handlers are coded as separate entities, they often perform similar duties. For example, after an unexpected exception or signal, a program may wish to free a held lock or release allocated heap storage before terminating. Throughout the remaining discussion, it is assumed that the destructor for stack allocated objects is given control for unexpected error conditions such as unhandled exceptions and signals.

A mechanism is described here which unifies cleanup and recovery processing by executing such code within a destructor of a specially designated, stack allocated object called a recovery object. For each execution scope for which protection (i.e., cleanup and/or recovery) is desired, a recovery object is declared on the stack. The recovery object is defined as follows:

Data

------

- Footprints

These are boolean flags which are set at various points of execution. There are two basic kinds of footprints - resourcefootprints and trace footprints. Resource footprints hold the value 'TRUE' when a given resource is allocated. For example, a resource footprint could be set to 'TRUE' when a lock is obtained and set to 'FALSE' when that lock is released. Trace footprints are set to 'TRUE' (and never set to 'FALSE' thereafter) to indicate a particular point of execution has been reached. For example, a trace footprint could be set to 'TRUE' to indicate that a function has

1

Page 2 of 5

reached its normal point of exit.

- Recovery Data

This is any information that might be required for cleanup or recovery. For example, lock information can be stored here so that a held lock may be released.

Methods

-----------

- Constructor

The constructor initializes the recovery object's data area (typically to zeroes).

- Destructor

The destructor is ex...