[J3] Question about LOCK_TYPE specifications

[Malcolm Cohen]

Hi Brad,

>A lock variable is unlocked...

This is the definition of what is locked or unlocked. It is not a constraint.

> All components have default initialization.

That is how we achieve the state that lock variables are defined (in the variable definition sense). It has nothing to do with the structure constructor - as you note, you cannot do anything interesting with the constructor; you can still do uninteresting things. 

Those two specifications work together to achieve lock variables being initially unlocked, no matter how they come into existence.

> a bit over specified

And your point is?

I cannot think of anything user-visible that these requirements and definitions unnecessarily prevent. If have something in mind, please enlighten us.

In the absence of user visibility, what is the implementation method that you want to use but which is forbidden by the requirements?

I will note that the purpose of these specifications is to ensure that lock variables work the way we want them to. Those specifications are probably sufficient, there is only a point in restricting them to what is strictly necessary if that would enable something useful. It is frequently the case that minimum conditions are more complicated than sufficient conditions, especially when it comes to comprehension and proving sufficiency.

> Why must they be *fully* default-initialized?

So they have defined values. We do not want holes in the definition. Holes mean the standard does not provide an interpretation. That would make it far more likely that the standard is ambiguous or contradictory. In my opinion, this particular requirement must remain as is.

> similar constraint that "Each nonallocatable component is fully default- initialized."

Once again, with feeling: that is not a "constraint". I know that in English there is wide ambiguity so one can use "constraint", "requirement", "rule" and at least a dozen other words simultaneously. When talking about the standard, however, we should strive to use words defined by the standard or by ISO more carefully.

Finally, a future revision can always relax requirements without serious risk of incompatibility. Thus, as long as the requirements specify the facility sufficiently well for both users and implementors, "overly strict" is not a problem.

Being "insufficiently strict" however is a big problem, for everyone: users, implementors, and future revisions. Tightening restrictions almost always introduces incompatibilities and the likelihood of some implementations having to change their behaviour (possibly even in user-visible ways), or worse: some implementations simply never bother to update their implementation of the feature to the new version, rendering the feature unreliable in actual use. That does not " promote portability, reliability, maintainability, and efficient execution" (our purpose!).

And so when I ask "what implementation method is it that you want to use but which is forbidden", I am very much open to any suggestions you might have, but that would be immediately followed by "how do you propose to specify things to provably maintain existing semantics".

Cheers,
-- 
..............Malcolm Cohen, NAG Oxford/Tokyo.

-----Original Message-----
From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Brad Richardson via J3
Sent: Thursday, July 25, 2024 4:48 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>
Subject: [J3] Question about LOCK_TYPE specifications

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