Rexx makes one exception to sequential processing-when a method sends a message to itself. Assume that method M1 has exclusive access to object O, and then tries to run a second, internal method M2, also belonging to O. Internal method M2 would try to run, but Rexx would delay it until the original method M1 finished. Yet M1 would be unable to proceed until M2 ran. The two methods would become deadlocked. In actual practice Rexx intervenes by treating internal method M2 like a subroutine call. In this case, Rexx runs method M2 immediately, then continues processing method M1.
The mechanism controlling this is the activity. Typically, whenever a message is invoked on an object, the activity acquires exclusive access by locking the object's scope. Any other activity sending a message to the object whose scope is locked must wait until the first activity releases the lock. The situation is different, however, if the messages originate from the same activity. When an invocation running on an activity sends another message to the same object, the method is allowed to run because the activity has already acquired the lock for the scope. Thus, Rexx permits nested, nonconcurrent method invocations on a single activity. No deadlocks occur because Rexx treats these additional messages as subroutine calls.