09-142 To: J3 From: Bill Long Subject: UTI's 155-158 - LOCK variables, C6 Date: 2009 February 10 References: 09-007, 09-102 Discussion: The wording in 09-007 describing variables of type LOCK_TYPE (lock variables) lack precision an clarity. Background: The intent is that a lock variable may have two "states", locked and unlocked. One value corresponds to the unlocked state, and is the same value as the structure constructor LOCK_TYPE(). Many values may represent the locked state, with the value depending on which image currently holds the lock. While there is no specified definition of the type, it is helpful to consider the simplest, most obvious possibility: type lock_type integer(atomic_int_kind),private :: owner = 0 end lock_type The unlocked state corresponds to the owner component having the value 0. The locked state corresponds to the owner component value equal to the image number of the image that executed a LOCK statement to change the owner value from 0. With this model, execution of a simple LOCK statement becomes an atomic operation of {If owner == 0, set owner = this_image()}. Execution of a simple UNLOCK statement becomes an atomic operation of {If owner == this_image(), set owner = 0}. UTI 155: The wording needs to be fixed to distinguish between the "value" of a lock variable (of which there are many possibilities) and the "state" of a lock variable (of which there are two possibilities). Edit is provided. It is not possible for a lock variable to be undefined. It is initially defined because all the components have default initialization, and the values change only by execution of LOCK or UNLOCK statements, both of which leave the lock variable defined. UTI 156: Constraint C608 can be split into two sentences to avoid confusion. UTI 157: It is reasonable to make the restriction that lock variables should not be changed by means other than LOCK and UNLOCK statements into a constraint. Edit supplied. UTI 158: A replacement Note is provided below to address the issues raised in UTI 158. ------------ Edits to 09-007: ------- [118:2] In 6.2.2 Lock variables, para1, sentence 2, replace "values" with "states", and add two new sentences after sentence 2 "The unlocked state is represented by the value LOCK_TYPE(). All other values represent the locked state." --------- [118:5-6] In 6.2.2 Lock variables, replace constraint C608 with: "C608 A variable of type LOCK_TYPE shall be a coarray. A variable with a LOCK_TYPE ultimate component shall be a coarray." --------- [118:7-8] In 6.2.2 Lock variables, convert para 2 into constraint C608a. -------------- [119:Note 6.2] Replace the contents of Note 6.2 at the end of 6.2.2 Lock variables with: "The restrictions against changing a lock variable except via the LOCK and UNLOCK statements ensure the integrity of its value and facilitate efficient implementation, particularly when special synchronization is needed for correct lock operation."