Resource management (computing): Difference between revisions

Revision as of 23:26, 25 July 2020

Latest revision as of 07:41, 24 July 2025

(14 intermediate revisions by 10 users not shown)

Line 1:

{{Short description|Techniques used by computers to manage components with limited availability}}

In [[computer programming]], '''resource management''' refers to techniques for managing [[System resource|resources]] (components with limited availability).

[[Computer program]]s may manage their own resources{{which|date=November 2016}} by using features exposed by [[programming language]]s ({{harvtxt|Elder|Jackson|Liblit|2008}} is a survey article contrasting different approaches), 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 (computer science)|garbage collection]] for memory. On many systems, the operating system reclaims resources after the process makes the [[exit (system call)|exit]] [[system call]].

==Controlling access==

Line 23 ⟶ 24:

{{main|resource contention}}

In computer science, [https://www.techtarget.com/whatis/definition/resource-contention resource contention] refers to a conflict that arises when multiple entities attempt to access a shared resource, like random access memory, disk storage, cache memory, internal buses, or external network devices.

{{expand section|date=November 2016}}

==Memory management==

Line 30 ⟶ 31:

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 (internal) memory management (since it is memory) and resource management (since it is managed by an external system). Examples include memory managed via native code and used from Java (via [[Java Native Interface]]); and objects in the [[Document Object Model]] (DOM), used from [[JavaScript]]. In both these cases, the [[Memory management|memory manager]] ([[Garbage collection (computer science)|garbage collector]]) of the [[runtime environment]] (virtual machine) is unable to manage the external memory (there is no shared memory management), and thus the external memory is treated as a resource, and managed analogously. However, cycles between systems (JavaScript referring to the DOM, referring back to JavaScript) can make management difficult or impossible.

==StackLexical management and heapexplicit management==

A key distinction in resource management within a program is between ''stacklexical management'' and ''heapexplicit management'' – whether a resource can be handled likeas having a lexical scope, such as a stack variable (lifetime is restricted to a single [[stacklexical frame]]scope, being acquired on entry to or within a particular scope, and released when execution exits that scope), or whether a resource must be handledexplicitly likeallocated aand heap variablereleased, such as a resource acquired within a function and then returned from it, which must then be released outside of the acquiring function. Stack Lexical management, iswhen applicable, allows a commonbetter useseparation case,of concerns and is significantlyless easier to handle than heap managementerror-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 (illustrated with opening a file in [[Python (programming language)|Python]]):

<syntaxhighlight lang="python">

deff work_with_file= open(filename: str):

...

f = open(filename)

f.close()

...

f.close()

</syntaxhighlight>

This is correct if the intervening <code>...</code> code does not contain an early exit (<code>return</code>), the language does not have exceptions, and <code>open</code> 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 <code>open</code> can fail.

Line 47:

The resource leak can be resolved in languages that support a <code>finally</code> construction (like Python) by placing the body in a <code>try</code> clause, and the release in a <code>finally</code> clause:

<syntaxhighlight lang="python">

deff work_with_file= open(filename: str):

try:

f = open(filename)

try:...

finally:

...

finally:f.close()

f.close()

</syntaxhighlight>

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 <code>try</code> clause, ensuring that the <code>finally</code> clause is only executed if the <code>open</code> code succeeds (without throwing an exception), assuming that "no exception" means "success" (as is the case for <code>open</code> in Python). If resource acquisition can fail without throwing an exception, such as by returning a form of <code>null</code>, it must also be checked before release, such as:

<syntaxhighlight lang="python">

deff work_with_file= open(filename: str):

try:

f = open(filename)

try:...

finally:

...

finallyif f:

if f:.close()

f.close()

</syntaxhighlight>

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 <code>with</code> statement in Python:

<syntaxhighlight lang="python">

defwith work_with_fileopen(filename: str) as f:

...

with open(filename) as f:

...

</syntaxhighlight>

The above techniques – unwind protection (<code>finally</code>) and some form of encapsulation – are the most common approach to resource management, found in various forms in [[C Sharp (programming language)|C#]], [[Common Lisp]], [[Java (programming language)|Java]], [[Python (programming language)|Python]], [[Ruby (programming language)|Ruby]], [[Scheme (programming language)|Scheme]], and [[Smalltalk]],{{sfn|Beck|1997|pp=37–39}} among others; they date to the late 1970s in the [[NIL (programming language)|NIL]] dialect of Lisp; see {{section link|Exception handling|History}}. There are many variations in the implementation, and there are also significantly different [[#Approaches|approaches]].

== Approaches ==

Line 134 ⟶ 131:

By contrast, in Python, a [https://docs.python.org/3/library/csv.html#csv.reader csv.reader] does not own the <code>file</code> that it is reading, so there is no need (and it is not possible) to close the reader, and instead the <code>file</code> itself must be closed.<ref>[https://stackoverflow.com/questions/3216954/python-no-csv-close Python: No csv.close()?]</ref>

<syntaxhighlight lang="Pythonpython">

with open(filename) as f:

r = csv.reader(f)

Line 142 ⟶ 139:

</syntaxhighlight>

In [[.NET Framework|.NET]], convention is to only have direct user of resources be responsible: "You should implement IDisposable only if your type uses unmanaged resources directly."<ref name="idisposable">{{cite web |url=https://msdn.microsoft.com/en-us/library/system.idisposable(v=vs.110).aspx |title=IDisposable Interface |accessdate=2016-04-03}}</ref>

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 (via destructors or finalizers); for example, the [[lapsed listener problem]] can occur and cause resource leaks if using the

Line 171 ⟶ 168:

| isbn = 978-0134769042

}}

* {{cite techreporttech report

|url = http://research.cs.wisc.edu/techreports/2008/TR1647.pdf

|first1 = Matt |last1 = Elder

Line 190 ⟶ 187:

* [http://c2.com/cgi/wiki?DeterministicResourceManagement Deterministic Resource Management], ''[[WikiWikiWeb]]''

[[Category:Articles with example Python (programming language) code]]

[[Category:Programming constructs]]