(j3.2006) Problem with LOCKED_BY_THIS_IMAGE
Wed Jun 11 18:34:30 EDT 2008
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
> 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(.NOT.LOCKED_BY_THIS_IMAGE(lock)) THEN ! Segment 2-A
ELSE IF(THIS_IMAGE()==1) THEN
????????LOCK(lock) ! Segment 1-A starts
According to our memory consistency restrictions, the access
to LOCKED_BY_THIS_IMAGE(lock) 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.
More information about the J3