Resource management (computing): Difference between revisions

Revision as of 23:45, 25 July 2020

Latest revision as of 07:41, 24 July 2025

(12 intermediate revisions by 9 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 35 ⟶ 36:

==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">

f = open(filename)

...

Line 46 ⟶ 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">

f = open(filename)

try:

Line 54 ⟶ 55:

</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">

f = open(filename)

try:

Line 63 ⟶ 64:

</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">

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 130 ⟶ 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 138 ⟶ 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 167 ⟶ 168:

| isbn = 978-0134769042

}}

* {{cite techreporttech report

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

|first1 = Matt |last1 = Elder

Line 186 ⟶ 187:

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

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

[[Category:Programming constructs]]