[J3] Question about LOCK_TYPE specifications

[Brad Richardson]

Hi all,

We were working through some things and ran into a question about some
of the constraints and specifications involving LOCK_TYPE, which also
tangentially involve EVENT_TYPE, NOTIFY_TYPE and TEAM_TYPE. It seems
like they are a bit over specified, so I'd be curious if anybody knows
the rationale for some of them.

First, from Sec 11.7.10 LOCK and UNLOCK statements its says that

> A lock variable is unlocked if and only if the value of each
component is the same as its default value. If it has any other value,
it is locked.

This seems to overly constrain possible implementations. Given that
there is no way to determine whether a LOCK_TYPE variable is locked or
unlocked other than to try and lock it, what does this constraint
achieve? It's worth noting that there's also no other way to change the
value of a LOCK_TYPE variable, as LOCK and UNLOCK statements are the
only place they can appear in a variable definition context.

Next, in 16.10.2.19 LOCK_TYPE it says:

> LOCK_TYPE is a derived type with private components; no component is
allocatable or a pointer. It is an extensible type with no type
parameters. All components have default initialization.
>
> ... The unlocked state is represented by the one value that is the
default value of a LOCK_TYPE variable; this is the value specified by
the structure constructor LOCK_TYPE ( )

Why the restriction to no allocatable or pointer components, or that
they all have default initialization? Also, the last sentence implies
that it's valid to use the intrinsic structure constructor for
LOCK_TYPE with no arguments, but I'm not sure why you'd want that,
since you can't do anything meaningful with the value it returns. You
can't assign it to anything or pass it as an argument to any procedures
since "A named variable with declared type LOCK_TYPE shall be a
coarray" and "A lock variable shall not appear in a variable definition
context".

EVENT_TYPE, NOTIFY_TYPE and TEAM_TYPE are seemingly allowed to have
allocatable or pointer components, but still have the similar
constraint that "Each nonallocatable component is fully default-
initialized." Why must they be *fully* default-initialized? Is this to
allow use of intrinsic structure constructors with no arguments? If so
why? You can't do anything with the values they return.

If anybody has some background info on why these restrictions on an
implementation are there I'd greatly appreciate it.

Regards,
Brad Richardson