System stack: Difference between revisions

Line 5:

Because of its limited size, a stack may "overflow" if too many function calls are made without returning. This situation is dangerous because, if not handled properly (usually by the program stopping and freeing all of its memory), the stack could intersect and overwrite other memory from the program, other programs, or the [[operating system]]. In high-integrity systems one of strict design requirements is predictability of the stack size. Use of [[heap]] is usually prohibited, for the same reason.

Often there ~~exist~~ more than one ''stack'':

Often there exists more than one ''stack'':

* In [[concurrent programming]] each [[task]] has a ''stack'' of its own. Differently to the [[heap]] ''~~stack~~'' need not to be shared between the [[task]]s and thus no interlocking is required;

* In [[concurrent programming]] each [[task]] has a ''stack'' of its own. Differently to the [[heap]], ''stacks'' need not to be shared between the [[task]]s and thus no interlocking is required;

* The language run-time environment may maintain multiple ''stacks'' for one [[task]]. For example, the arguments and the local variables of a subprogram may be allocated on a stack different from the stack used for the return. When the subprograms ~~may~~ return variable size ~~values~~ this prevents ~~copying~~ of ~~those~~. Upon return stacks are swapped;

* The language run-time environment may maintain multiple ''stacks'' for one [[task]]. For example, the arguments and the local variables of a subprogram may be allocated on a stack different from the stack used for the return. When the subprograms are allowed to return values of variable size, this prevents confusion between return values and local variables. Upon return stacks are swapped;

* Secondary ''stacks'' may be used for allocation of non-contiguous objects, typically strings.