(j3.2006) Problem with LOCKED_BY_THIS_IMAGE

[Aleksandar Donev]

Hello,

I was not at the last meeting and could not contribute to the new LOCK/UNLOCK 
functionality. I am not sure why LOCKED_BY_THIS_IMAGE was added. Bill gave me 
one example:
> You might want to test to see if you
> already own the lock, in which case you proceed, and if not, you obtain
> the lock first.
but LOCK with a STAT specifier already does that.

Assuming this function is actually useful and kept, there is a problem with 
the current wording. Consider the example:

IF(THIS_IMAGE()==2) THEN
????????IF(.NOT.LOCKED_BY_THIS_IMAGE(lock[1])) THEN ! Segment 2-A
????????????????LOCK(lock[1])
????????END IF
ELSE IF(THIS_IMAGE()==1) THEN
????????LOCK(lock[1]) ! Segment 1-A starts
END IF

According to our memory consistency restrictions, the access 
to LOCKED_BY_THIS_IMAGE(lock[1]) in segment 2-A must be ordered with respect 
to the locking in segment 1-A, so the above code would in fact be illegal. I 
personally do not see why we are allowing a variable to be examined while 
other images are modifying it, even if it is a lock. In particular, it forces 
the processor to use atomic instructions for setting/reading the field that 
says who owns the lock (thus, it cannot be a single bit).

So, if this function is to remain in the language, we need to explicitly 
exempt references to lock variables in calls to this intrinsic function in 
our memory consistency rules. I can write the edits if I am first convinced 
this function is actually needed/useful.

One more comment: I do not like the keyword LOCKED= in the LOCK statement---it 
will confuse people. Is it referring to "already locked" or "just locked". I 
know it is the latter, but some will think it is the first. This is why I 
proposed SUCCESS---it is clear to the reader what it means.

Best,
Aleks