Content deleted Content added
Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5 |
|||
| (16 intermediate revisions by 13 users not shown) | |||
Line 1:
{{short description|Behavioral rules for all elements of a programming language}}
{{Program execution}}
A programming language consists of a grammar/syntax plus an '''execution model'''. The execution model specifies the behavior of elements of the language. By applying the execution model, one can derive the behavior of a program that was written in terms of that programming language. For example, when a programmer "reads" code, in their mind, they walk through what each line of code does. In effect they simulate the behavior inside their mind. What the programmer is doing is applying the execution model to the code, which results in the behavior of the code.▼
▲
Each and every programming language has an execution model, which determines the manner in which the units of work (that are indicated by program [[Syntax (programming languages)|syntax]]) are [[Scheduling (computing)|scheduled]] for [[Execution (computing)|execution]]. Detailed examples of the specification of execution models of a few popular languages include those of Python,<ref>▼
▲Each and every programming language has an execution model, which determines the manner in which the units of work (that are indicated by program
{{cite web
| url=https://docs.python.org/3/reference/executionmodel.html
| title=Python Documentation: Execution Model
}}</ref>
the execution model of the [[Unified Parallel C]] (UPC) programming language,
<ref>{{cite web
| url=http://upc.lbl.gov/lang-overview.shtml
| title=UPC Language Features
}}</ref>
a discussion of various classes of execution model such as for [[Imperative programming|imperative]] versus [[Functional programming|functional languages]],<ref>
{{cite
| url=https://books.google.com/books?id=4xwWNCiF9CgC&
| title=Programming Languages and Execution Models
| author1=Cardoso, J.M.P.
Line 22 ⟶ 24:
| publisher=Springer US
}}</ref>
and an article discussing execution models for [[Real-time computing|real-time embedded]] languages.<ref>{{cite journal
| url=http://pertsserver.cs.uiuc.edu/~mcaccamo/papers/PREM_rtas11.pdf
| title=A Predictable Execution Model for COTS-based Embedded Systems
Line 34 ⟶ 35:
| author6=CACCAMO, M.
| author7=KEGLEY, R
|
| publisher=IEEE
| journal=Real-Time and Embedded Technology and Applications Symposium
| access-date=2015-05-20
| archive-date=2017-08-12
}}</ref>▼
| archive-url=https://web.archive.org/web/20170812100818/http://pertsserver.cs.uiuc.edu/~mcaccamo/papers/PREM_rtas11.pdf
| url-status=dead
▲ }}</ref>
== Details of an execution model ==
Line 47 ⟶ 51:
To illustrate this, consider the [[C (programming language)|C programming language]], as described in the book by Kernighan and Richie.<ref name="k&r1e">{{cite book | last=Kernighan | first=Brian W. | authorlink=Brian Kernighan | author2=Dennis M. Ritchie | title=The C Programming Language | edition=1st | publisher=[[Prentice Hall]] | date=February 1978 | ___location=[[Englewood Cliffs, NJ]] | isbn=0-13-110163-3 | authorlink2=Dennis M. Ritchie | url-access=registration | url=https://archive.org/details/cprogramminglang00kern }}</ref>
C has a concept called a statement. The language specification defines a statement as a chunk of syntax that is terminated by a ";". The language spec then says that "execution of the program proceeds one statement after the other, in sequence". Those words: "execution of the program proceeds one statement after the other, in sequence" are one piece of the execution model of C
The C language actually has an additional level to its execution model, which is the order of precedence. Order of precedence states the rules for the order of operations within a single statement. The order of precedence can be viewed as stating the constraints on performing the units of work that are within a single statement. So, ";" and "IF" and "WHILE" cover constraints on the order of statements, while order of precedence covers constraints on work within a statement. Hence, these parts of the C language specification are also part of the execution model of the C language.
Line 58 ⟶ 62:
However, an [[Interpreter_(computing)|interpreter]] may also be constructed for any language, in which case all decisions on order of execution are dynamic. An [[Interpreter_(computing)|interpreter]] can be viewed as being part translator, and part execution model implementation.
== Assembly language execution model versus implementation by micro-architectures ==
Line 66 ⟶ 68:
== Parallel Execution Models ==
In the modern age, parallel programming is an increasingly important topic. Parallel execution models tend to be complex because they involve multiple timelines. Parallel execution models necessarily include the behavior of [[Synchronization_construct| synchronization constructs]]. A synchronization construct has the effect of establishing an ordering between activities in one timeline relative to activities in another timeline.
For example, a common synchronization construct is the lock. Consider one timeline. The timeline has a point at which it executes the "gain ownership of the lock" synchronization construct. In Posix threads this would be pthread_mutex_lock(&myMutex). In Java this would be lock.lock(). In both cases, the timeline is called a thread. The C and Java execution models are sequential, and they state that the timeline has activities that come before the call to "gain ownership of the lock", and activities that come after the call. Likewise there is a "give up ownership of the lock" operation. In C this would be pthread_mutex_unlock(&myMutex). In Java this would be lock.unlock(). Again, the execution models C and Java define that one group of statements is executed before ownership of the lock is given up, and another group of statements is executed after ownership of the lock is given up.
Line 78 ⟶ 80:
"In the case that ownership of the lock goes from thread A to thread B, A-post-gain-lock statements come before B-post-gain-lock statements."
The complication comes from the fact that the execution model does not have any means for the execution of "give up ownership of the lock" to have any influence over which execution of "gain ownership of the lock" in some other timeline (thread) follows. Very often, only certain handoffs give valid results. Thus, the programmer must think of all possible combinations of one thread giving up a lock and another thread getting it next, and make sure their code only allows valid combinations.
== See also ==
| |||