Resource management (computing)
In computer programming, resource management refers to techniques for managing resources.
Computer programs may manage their own resources by using features exposed by programming languages, or may elect to manage them by a host – an operating system or virtual machine – or another program.
Host-based management is known as resource tracking, and consists of cleaning up resource leaks: terminating access to resources that have been acquired but not released after use. This is known as reclaiming resources, and is analogous to garbage collection for memory. On many systems the operating system reclaims resources after the process makes the exit system call.
Controlling access
The omission of releasing a resource when a program has finished using it is known as a resource leak, and is an issue in sequential computing. Multiple processes wish to access a limited resource can be an issue in concurrent computing, and is known as resource contention.Resource management seeks to control access in order to prevent both of these situations.
Resource leak
Formally, resource management consists of ensuring that a resource is released if and only if it is successfully acquired. This general problem can be abstracted as "before, body, and after" code, which normally are executed in this order, with the condition that the after code is called if and only if the before code successfully completes, regardless of whether the body code executes successfully or not. This is also known as execute around or a code sandwich, and occurs in various other contexts, such as a temporary change of program state, or tracing entry and exit into a subroutine. However, resource management is the most commonly cited application. In aspect-oriented programming, such execute around logic is a form of advice.In the terminology of control flow analysis, resource release must postdominate successful resource acquisition; failure to ensure this is a bug, and a code path that violates this condition causes a resource leak. Resource leaks are often minor problems, generally not crashing the program, but instead causing some slowdown to the program or the overall system. However, they may cause crashes – either the program itself or other programs – due to resource exhaustion: if the system runs out of resources, acquisition requests fail. This can present a security bug if an attack can cause resource exhaustion. Resource leaks may happen under regular program flow – such as simply forgetting to release a resource – or only in exceptional circumstances, such as when a resource is not released if there is an exception in another part of the program. Resource leaks are very frequently caused by early exit from a subroutine, either by a
return statement, or an exception raised either by the subroutine itself, or a deeper subroutine that it calls. While resource release due to return statements can be handled by carefully releasing within the subroutine before the return, exceptions cannot be handled without some additional language facility that guarantees that release code is executed.More subtly, successful resource acquisition must dominate resource release, as otherwise the code will try to release a resource it has not acquired. The consequences of such an incorrect release range from being silently ignored to crashing the program or unpredictable behavior. These bugs generally manifest rarely, as they require resource allocation to first fail, which is generally an exceptional case. Further, the consequences may not be serious, as the program may already be crashing due to failure to acquire an essential resource. However, these can prevent recovery from the failure, or turn an orderly shutdown into a disorderly shutdown. This condition is generally ensured by first checking that the resource was successfully acquired before releasing it, either by having a boolean variable to record "successfully acquired" – which lacks atomicity if the resource is acquired but the flag variable fails to be updated, or conversely – or by the handle to the resource being a nullable type, where "null" indicates "not successfully acquired", which ensures atomicity.
Resource contention
Memory management
Memory can be treated as a resource, but memory management is usually considered separately, primarily because memory allocation and deallocation is significantly more frequent than acquisition and release of other resources, such as file handles. Memory managed by an external system has similarities to both memory management and resource management. Examples include memory managed via native code and used from Java ; and objects in the Document Object Model, used from JavaScript. In both these cases, the memory manager of the runtime environment is unable to manage the external memory, and thus the external memory is treated as a resource, and managed analogously. However, cycles between systems can make management difficult or impossible.Lexical management and explicit management
A key distinction in resource management within a program is between lexical management and explicit management – whether a resource can be handled as having a lexical scope, such as a stack variable, or whether a resource must be explicitly allocated and released, such as a resource acquired within a function and then returned from it, which must then be released outside of the acquiring function. Lexical management, when applicable, allows a better separation of concerns and is less error-prone.Basic techniques
The basic approach to resource management is to acquire a resource, do something with it, then release it, yielding code of the form :f = open
...
f.close
This is correct if the intervening
... code does not contain an early exit, the language does not have exceptions, and open is guaranteed to succeed. However, it causes a resource leak if there is a return or exception, and causes an incorrect release of unacquired resource if open can fail.There are two more fundamental problems: the acquisition-release pair is not adjacent, and resource management is not encapsulated – the programmer must manually ensure that they are always paired. In combination, these mean that acquisition and release must be explicitly paired, but cannot be placed together, thus making it easy for these to not be paired correctly.
The resource leak can be resolved in languages that support a
finally construction by placing the body in a try clause, and the release in a finally clause:f = open
try:
...
finally:
f.close
This ensures correct release even if there is a return within the body or an exception thrown. Further, note that the acquisition occurs before the
try clause, ensuring that the finally clause is only executed if the open code succeeds, assuming that "no exception" means "success". If resource acquisition can fail without throwing an exception, such as by returning a form of null, it must also be checked before release, such as:f = open
try:
...
finally:
if f:
f.close
While this ensures correct resource management, it fails to provide adjacency or encapsulation. In many languages there are mechanisms that provide encapsulation, such as the
with statement in Python:with open as f:
...
The above techniques – unwind protection and some form of encapsulation – are the most common approach to resource management, found in various forms in C#, Common Lisp, Java, Python, Ruby, Scheme, and Smalltalk, among others; they date to the late 1970s in the NIL dialect of Lisp; see. There are many variations in the implementation, and there are also significantly different [|approaches].
Approaches
Unwind protection
The most common approach to resource management across languages is to use unwind protection, which is called when execution exits a scope – by execution running off the end of the block, returning from within the block, or an exception being thrown. This works for stack-managed resources, and is implemented in many languages, including C#, Common Lisp, Java, Python, Ruby, and Scheme. The main problems with this approach is that the release code may be very distant from the acquisition code, and that the acquisition and release code must always be paired by the caller. These can be remedied either functionally, by using closures/callbacks/coroutines, or by using an object that handles both the acquisition and release, and adding a language construct to call these methods when control enters and exits a scope ; see below.An alternative, more imperative approach, is to write asynchronous code in direct style: acquire a resource, and then in the next line have a deferred release, which is called when the scope is exited – synchronous acquisition followed by asynchronous release. This originated in C++ as the ScopeGuard class, by Andrei Alexandrescu and Petru Marginean in 2000,
with improvements by Joshua Lehrer, and has direct language support in D via the
scope keyword, where it is one approach to exception safety, in addition to RAII. It has also been included in Go, as the Object-oriented programming
In object-oriented programming, resources are encapsulated within objects that use them, such as afile object having a field whose value is a file descriptor. This allows the object to use and manage the resource without users of the object needing to do so. However, there is a wide variety of ways that objects and resources can be related.Firstly, there is the question of ownership: does an object have a resource?
- Objects can own resources.
- Objects can view resources.
- Objects can communicate with other objects that have resources.
- Acquire/release while the object is valid, via methods such as
openordispose. - Acquire/release during object creation/destruction.
- Neither acquire nor release the resource, instead simply having a view or reference to a resource managed externally to the object, as in dependency injection; concretely, an object that has a resource is passed in as an argument to a method or constructor.
dispose. This is analogous to traditional file management, and is known as the dispose pattern. This is the basic approach used in several major modern object-oriented languages, including Java, C# and Python, and these languages have additional constructs to automate resource management. However, even in these languages, more complex object relationships result in more complex resource management, as discussed below.RAII
A natural approach is to make holding a resource be a class invariant: resources are acquired during object creation, and released during object destruction. This is known as Resource Acquisition Is Initialization, and ties resource management to object lifetime, ensuring that live objects have all necessary resources. Other approaches do not make holding the resource a class invariant, and thus objects may not have necessary resources, resulting in errors such as trying to read from a closed file. This approach ties resource management to memory management, so if there are no memory leaks, there are no resource leaks. RAII works naturally for heap-managed resources, not only stack-managed resources, and is composable: resources held by objects in arbitrarily complicated relationships are released transparently simply by object destruction.RAII is the standard resource management approach in C++, but is little-used outside C++, despite its appeal, because it works poorly with modern automatic memory management, specifically tracing garbage collection: RAII ties resource management to memory management, but these have significant differences. Firstly, because resources are expensive, it is desirable to release them promptly, so objects holding resources should be destroyed as soon as they become garbage. Object destruction is prompt in deterministic memory management, such as in C++ or in deterministic reference-counting, and thus RAII works well in these situations. However, most modern automatic memory management is non-deterministic, making no guarantees that objects will be destroyed promptly or even at all! This is because it is cheaper to leave some garbage allocated than to precisely collect each object immediately on its becoming garbage. Secondly, releasing resources during object destruction means that an object must have a finalizer – the object cannot simply be deallocated – which significantly complicates and slows garbage collection.
Complex relationships
When multiple objects rely on a single resource, resource management can be complicated.A fundamental question is whether a "has a" relationship is one of owning another object, or viewing another object. A common case is when one two objects are chained, as in pipe and filter pattern, the delegation pattern, the decorator pattern, or the adapter pattern. If the second object holds a resource, is the first object responsible for managing the resource? This is generally answered identically to whether the first object owns the second object: if so, then the owning object is also responsible for resource management, while if not, then it is not. Further, a single object may "have" several other objects, owning some and viewing others.
Both cases are commonly found, and conventions differ. Having objects that use resources indirectly be responsible for the resource provides encapsulation, but results in considerable complexity, particularly when a resource is shared by multiple objects or objects have complex relationships. If only the object that directly uses the resource is responsible for the resource, relationships between other objects that use the resources can be ignored, but there is no encapsulation : the resource must be managed directly, and might not be available to the indirectly using object.
Implementation-wise, in object composition, if using the dispose pattern, the owning object thus will also have a
dispose method, which in turn calls the dispose methods of owned objects that must be disposed; in RAII this is handled automatically. In object aggregation, nothing needs to be done by the viewing object, as it is not responsible for the resource.Both are commonly found. For example, in the Java Class Library,
close on the BufferedReader in turn closes the InputStreamReader, which in turn closes the FileInputStream, which in turn releases the system file resource. Indeed, the object that directly uses the resource can even be anonymous, thanks to encapsulation:try )
// reader is closed when the try-with-resources block is exited, which closes each of the contained objects in sequence.
However, it is also possible to manage only the object that directly uses the resource, and not use resource management on wrapper objects:
try ))
// stream is closed when the try-with-resources block is exited.
// reader is no longer usable after stream is closed, but so long as it does not escape the block, this is not a problem.
By contrast, in Python, a does not own the
file that it is reading, so there is no need to close the reader, and instead the file itself must be closed.with open as f:
r = csv.reader
# Use r.
- f is closed when the with-statement is exited, and can no longer be used.
- Nothing is done to r, but the underlying f is closed, so r cannot be used either.
In.NET, convention is to only have direct user of resources be responsible: "You should implement IDisposable only if your type uses unmanaged resources directly."
In case of a more complicated object graph, such as multiple objects sharing a resource, or cycles between objects that hold resources, proper resource management can be quite complicated, and exactly the same issues arise as in object finalization ; for example, the lapsed listener problem can occur and cause resource leaks if using the
observer pattern. Various mechanisms exist to allow greater control of resource management. For example, in the Google Closure Library, the
registerDisposable method to register other objects to be disposed with this object, together with various lower-level instance and class methods to manage disposal.