Content deleted Content added
decompress overly prescriptive introduction |
merge |
||
Line 5:
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
Resource management includes both preventing [[resource leak]]s (the act of refusing to release a resource when a process has finished using it) and dealing with [[resource contention]] (when multiple processes wish to access a limited resource).
Line 14:
Resource leaks are an issue in sequential computing, while resource contention is an issue in [[concurrent computing]].
Formally, resource management (preventing resource leaks) 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 a ''code sandwich,'' and occurs in various other contexts,{{sfn|Elder|Jackson|Liblit|2008|p=3}} such as a temporary change of program state, or [[Tracing (software)|tracing]] entry and exit into a [[subroutine]]. However, resource management is the most commonly cited application.▼
In the terminology of [[control flow analysis]], resource release must [[postdominate]] successful resource acquisition;{{sfn|Elder|Jackson|Liblit|2008|p=2}} 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.{{sfn|Elder|Jackson|Liblit|2008|p=3}} 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 [[Structured programming#Early exit|early exit]] from a subroutine, either by a <code>return</code> 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 [[Dominator (graph theory)|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===
Line 29 ⟶ 33:
A key distinction in resource management within a program is between ''stack management'' and ''heap management'' – whether a resource can be handled like a stack variable (lifetime is restricted to a single [[stack frame]], being acquired on entry to or within a particular scope, and released when execution exits that scope), or whether a resource must be handled like a heap variable, such as a resource acquired within a function and then returned from it, which must then be released outside of the acquiring function. Stack management is a common use case, and is significantly easier to handle than heap management.
▲Formally, resource management (preventing resource leaks) 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 a ''code sandwich,'' and occurs in various other contexts,{{sfn|Elder|Jackson|Liblit|2008|p=3}} such as a temporary change of program state, or [[Tracing (software)|tracing]] entry and exit into a [[subroutine]]. However, resource management is the most commonly cited application.
▲In the terminology of [[control flow analysis]], resource release must [[postdominate]] successful resource acquisition;{{sfn|Elder|Jackson|Liblit|2008|p=2}} 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.{{sfn|Elder|Jackson|Liblit|2008|p=3}} 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 [[Structured programming#Early exit|early exit]] from a subroutine, either by a <code>return</code> 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 [[Dominator (graph theory)|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.
==Basic techniques==
| |||