09-142r2 To: J3 From: Bill Long Subject: UTI's 155-158 - LOCK variables, C6 Date: 2009 February 11 References: 09-007, 09-102 Discussion: The wording in 09-007 describing variables of type LOCK_TYPE (lock variables) lack precision and 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}. After consideration, it was determined that the material in 6.2.2 is better located in 13. Paper 09-143r2 contains the edits for clause 13. ------------ Edits to 09-007: [118:1 - 119:Note 6.2] Delete all of 6.2.2 Lock variable.