An intentional race condition in a ParaSail concurrent loop

An intriguing question, given the presence of the concurrent loop construct in ParaSail, is what would happen if there were a loop exit or a return statement in the body of a concurrent loop.  Earlier we have said that only forward and reverse loops would allow an exit statement.  But perhaps we should allow an exit or a return from within a concurrent loop as a way of terminating a concurrent computation, aborting all threads besides the one exiting or returning.  This would essentially be an intentional race condition, where the first thread to exit or return wins the race.  This would seem to be a relatively common paradigm when doing a parallel search, where you want to stop as soon as the item of interest is found in the data structure being walked, for example, and there is no need for the other threads to continue working.

In some sense, a return statement in a concurrent loop is easier to understand, if we presume we are in a function searching (in parallel) for some item in a data structure, and we want to return the item as soon as any thread finds it.  An exit statement in a concurrent loop is a bit harder to understand, since we would need a way to record the result of the winning thread somehow.  Perhaps we would want to allow some code associated with the exit statement that occurs after all of the other threads have been aborted.  Perhaps "exit loop then record winner;" might be a syntax indicating that the record winner code is to be executed after the loop has effectively been stopped, but still in the context of the winning thread, with visibility on the local variables of the loop body containing the exit loop then ... construct.

For example, using the generalized for loop from the previous posting:

    var Winner : Node := null;
    for T := Root then T.Left || T.Right 
      while T != null concurrent loop
        if T.Key == Desired_Key then
            exit loop then Winner := T;
        end if;
    end loop;

At this point Winner is either still null if no node in the tree has the Desired_Key, or is equal to some node whose Key equals the Desired_Key. If there is more than one such node, it would be non-deterministic which such node Winner designates. 

Clearly this kind of brute force search of the tree would not be needed if the tree were organized based on Key values.  This example presumes the Key is not controlling the structure of the tree.  Also note that if this were a function whose whole purpose was to find the node of interest, the exit loop then ... statement could presumably be replaced by simply return T and we wouldn't need the local variable Winner at all.