Meaning of "update" for shared actual paramete DRAFT 84-12-10 AI-00141/03 1 | !standard 09.11 (09) 84-12-10 AI-00141/03 | !standard 06.02 (01) | !class binding interpretation 84-02-06 (provisional classification) | !status work-item 84-12-10 | !status WG14 referred back to committee 84-11-27 | !status board-approved 84-11-26 | !status committee-approved 84-02-06 | !status work-item 83-12-14 | !topic Meaning of "update" for shared actual parameters | | !summary 84-05-14 (DRAFT) The synchronization point implied by the "update" of a SHARED variable used as an actual in out or out parameter is the point at which the value of the formal parameter is copied to the actual parameter. | !question 84-09-26 (DRAFT) What is the synchronization point associated with the update of a SHARED variable used as an in out or out parameter in a procedure or entry call? | !recommendation 84-05-14 (DRAFT) The synchronization points induced by the "update" of a SHARED variable should include the points at which that variable is copied back during a procedure or entry call. | !discussion 84-03-16 (DRAFT) Section 9.11(9) says "The pragma SHARED can be used to specify that every read or update of a variable is a synchronization point for that variable...." Section 6.2(1) defines "update" as follows. "The value of a variable is said to be updated when an assignment is performed to the variable, and also (indirectly) when the variable is used as actual parameter of a subprogram call or entry call statement that updates its value." Intuitively, the "use" of a variable as an actual in out or out parameter might be thought to extend from the beginning to the end of a procedure or entry call, especially since records and arrays may be passed by reference. Scalar and access parameters, however, are passed by copy [6.2(6)] and the value of a scalar (or access) formal parameter is only copied back to the actual parameter when the procedure or entry returns. For such parameters, the Standard should be understood to mean that the parameter is only "used" (i.e., updated) when the value of the formal parameter is copied to the actual parameter. Since the pragma SHARED can only name scalar and access variables, the implication is that when such variables are used as in out or out parameters, there is one synchronization point when the variable is evaluated (prior to copying its value to the formal parameter) and one when the value of the formal parameter is copied back to the actual parameter. Meaning of "update" for shared actual paramete DRAFT 84-12-10 AI-00141/03 2 | !wording 84-05-14 (DRAFT) | | Change the first sentence of 9.11(9) to read | | "The pragma SHARED can be used to specify that every read of and every | assignment to a variable is a synchronization point for that variable, | including those that occur during the copy-in or copy-back when that | variable is used as an actual parameter. That is, the above | assumptions...." | | Alternatively, change the definition of "update" in 6.2. | | !appendix 83-12-14 | | ****************************************************************************** | | !section 09.11 Frank Prindle 83-06-20 83-00103 | !version 1983 | !topic meaning of pragma SHARED | | What is clear about variables declared SHARED is that reads and updates by | multiple tasks are interlocked so as to guarantee indivisible access. What | is not clear is what exactly constitutes an "update" of a variable. For | example: | i := i+3; | | if (i>7) then i := 0; endif; | | i := exfunc(i); [exfunc is some | function] | | j := i; j := j+1; i := j; | | are all, in a sense, updates of the variable "i". If two tasks are | executing "i := i+3;", am I to assume that it is guaranteed that, when both | have done it, that i will be 6 greater than before either task executed that | statement? I would hope so, but I am afraid the compiler might not be able | to identify the beginning and end of the "update" in more complex cases. | The last paragraph in 9.11 confuses the issue by specifying that a given | implementation "must" restrict the objects for which the pragma SHARED is | allowed to objects for which direct reading and direct updating is | implemented as an indivisible | operation. I certainly can understand the confusion about shared variables. | | ****************************************************************************** | | !section 09.11 P. N. Hilfinger 83-06-20 83-00104 | !version | !topic Meaning of SHARED pragma (83-00103) | | Prindle has pointed out a certain ambiguity in the wording of the discussion | of the SHARED pragma in section 9.11. Actually, there is less ambiguity Meaning of "update" for shared actual paramete DRAFT 84-12-10 AI-00141/03 3 | than he indicates, but there is a problem with the current definition of the | term "update." Section 9.11 says first that assignments and reads of a | SHARED object are indivisible. Second, it says that each read and update is | a synchronization point. The term "update" is defined in section 6.2: | | "The value of a variable is said to be updated when an assignment | is performed to the variable, and also (indirectly) when the | variable is used as actual parameter of a subprogram call or | entry call statement that updates its value...." | | The problem is that the second clause of this definition is not well-defined | for concurrent processes. In particular, the phrase "when ... is used" is | quite vague. On the other hand, it is quite clear from the definition that | any of the fragments | | i:=i+3; | | if (i>7) then i:=0; endif; | | j:=i; j:=j+1; i:=j; | | is NOT an indivisible update. It is also clear (in answer to Prindle's | parenthetical question) that it is quite irrelevant whether the hardware or | something else implements indivisible access; the last paragraph of 9.11 | means (and should have read) "Direct reading and direct updating of an | object mentioned in a SHARED pragma is indivisible. An implementation may | restrict the objects that may be mentioned." | | What isn't clear is where the synchronization points occur during a | procedure call when a SHARED variable is an actual. In that case, an update | of the actual cannot be a synchronization POINT, since it isn't a point, but | rather "[the use of the variable] as actual parameter of a subprogram call | ... that updates its value," which presumably extends over a period of time | from the call of the procedure to its exit. I presume the intention here is | that the initial copy-in and final copy-back (these are scalar and | access-type variables) are the points of update.