To: J3                                                     J3/24-160
From: Brad Richardson
Subject: Edits to Allow Efficient LOCK_TYPE Implementation
Date: 2024-October-04

Reference: 24-007

1. Introduction

The normative text dictates implementation of LOCK_TYPE in such a way
that is unnecessary, and precludes efficient implementations. This paper
provides edits which alleviate this restriction.

For example, it may be desirable for some implementations for a LOCK_TYPE
variable to have an allocatable or pointer component that tracks what
images may be waiting to acquire a lock, or that have recently released a
lock, as a method of providing efficient or fair implementations. This
additionally brings the specification of LOCK_TYPE into closer alignment
with the wording on EVENT_TYPE and NOTIFY_TYPE, both of which share
similar design requirements.

2. Edits for LOCK_TYPE

[461:6+] 16.10.2.19 LOCK_TYPE first paragraph
    delete the last phrase of the first sentence:
  "; no component is allocatable or a pointer"
    and change the last sentence to
  "Each nonallocatable component is fully default-initialized to an
  unlocked state."
    making the whole paragraph read:
  "LOCK_TYPE is a derived type with private components. It is an
  extensible type with no type parameters. Each nonallocatable component
  is fully default-initialized to an unlocked state.

[461:8+] 16.10.2.19 LOCK_TYPE second paragraph
    change the 3rd and 4th sentences to
  "The initial state of a lock variable is unlocked."
    making the whole paragraph read:
  "A scalar variable of type LOCK_TYPE is a lock variable. A lock variable
  can have one of two states: locked and unlocked. The initial state of a
  lock variable is unlocked. The value of a lock variable can be changed
  with the LOCK and UNLOCK statements (11.7.10).

===END===