Issue 6111: Reentrancy 1 (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: How is the effect if isReentrant achieved for actions other than call actions? isReentrant is only on behaviors. Perhaps it should also be available on actions and operations Resolution: The current semantics of isReentrant on behaviors leads to unexpected global mutual exclusion of invocation of a behavior if isReentrant=false, the default (see Issue 9873). However, at the level of the invocation of a behavior in an activity, it is often the case that one execution of such an invocation action should complete before a second can begin (for example, if the activity is modeling a business process with the invoked behavior assigned to a single person, or a manufacturing process with the behavior carried out by a single piece of equipment). Thus, it is reasonable to have "local" non-reentrancy as the default. In this case, however, it makes as much sense to allow the specification of reentrancy or non-reentrancy on any action, not just on the invocation of a behavior, as requested by the issue submitter. This also allows locally non-reentrant semantics, without the unexpected consequences of global non-reentrancy. Revised Text: In Figure 12.2, add the attribute declaration "isLocallyReentrant: Boolean = false" inside the class box for Action. In Subclause 12.3.2 Action, under Attributes, add at the beginning: Package FundamentalActivities · isLocallyReentrant: Boolean If true, the action can begin a new, concurrent execution, even if there is already another execution of the action ongoing. If false, the action cannot begin a new execution until any previous execution has completed. The default is false. Under Semantics, replace the paragraph If a behavior is not reentrant, then no more than one execution of it will exist at any given time. An invocation of a nonreentrant behavior does not start the behavior when the behavior is already executing. In this case, control tokens are discarded, and data tokens collect at the input pins of the invocation action, if their upper bound is greater than one, or upstream otherwise. An invocation of a reentrant behavior will start a new execution of the behavior with newly arrived tokens, even if the behavior is already executing from tokens arriving at the invocation earlier. with: If an action is not locally reentrant (isLocallyReentrant=false, the default), then no more than one execution of it will exist at any given time within the context of a single execution of the containing activity. Even if the action would normally begin an execution according to the rules above, it will not start a new execution if there is already one ongoing within the same activity execution. In this case, the action simply does not accept any tokens offered to it until its ongoing execution has finished. At this point, if the required tokens are still available, the action may accept the offers and begin a new execution. On the other hand, if an action is locally reentrant (isLocallyReentrant=true), then it will begin a new execution any time the rules above allow it, even if there are one or more executions already going within the same activity execution. This means that there may be, within any one execution of the containing activity, more than one concurrent execution of the action ongoing at any given time. A call action for a non-reentrant behavior will also act locally non-reentrant, whatever the value of the isLocallyReentrant property for the action. Moreover, an invocation action for a non-reentrant behavior will not execute if there is any currently running execution for the behavior, whether invoked by this action or any other (see "CallAction" (from Basic Actions) on page xxx). In Subclause 11.3.8, under Semantics, after the first paragraph, add: If the behavior invoked by a call action is not reentrant, then no more than one execution of it will exist at any given time. An invocation of a non-reentrant behavior does not start the behavior when the behavior is already executing. An invocation of a reentrant behavior may start a new execution of the behavior when offered the required tokens, even if the behavior is already executing. However, it will not invoke the behavior if there is an ongoing behavior execution invocated by the same action within the same activity execution, and the action has isLocallyReentrant=false (see "Action" (from CompleteActivities, FundamentalActivities, StructuredActivities) on page xxx). Disposition: Resolved Actions taken: August 30, 2003: received issue April 26, 2010: closed issue April 26, 2010: closed issue Discussion: A resolution of this issue has to await further clarification of the activity view of reentrancy. This issue should be resolved in a manner consistent with activities, if possible. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification. End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Reentrancy 1 How is the effect if isReentrant achieved for actions other than call actions? isReentrant is only on behaviors. Perhaps it should also be available on actions and operations. Discussion: The attribute "isReentrant" indicates whether a behavior can be invoked while it is still executing from a previous invocation. It is not the action that invokes the behavior that is reentrant, but the behavior. Thus putting this attribute on action would not be sensible. Operation is a specification that a classifier will response to an invocation by executing a behavior. Again, it is not the specification that is reentrant, but the behavior. Disposition: Closed, no change OMG Issue No: 6111 Title: Reentrancy 1 Source: Kabira Technologies, Inc.NIST (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: How is the effect if isReentrant achieved for actions other than call actions? isReentrant is only on behaviors. Perhaps it should also be available on actions and operations Discussion: The attribute "isReentrant" indicates whether a behavior can be invoked while it is still executing from a previous invocation. It is not the action that invokes the behavior that is reentrant, but the behavior. Thus putting this attribute on action would not be sensible. [Conrad: OK. I meant that actions other than invocation actions might be reentrant or not, but on second thought, it seems like it doesn't make sense for other actions.]Operation is a specification that a classifier will response to an invocation by executing a behavior. Again, it is not the specification that is reentrant, but the behavior. [Conrad: Agreed, but this requires looking into the object at runtime to see if the behavior that will receive the dispatch is reentrant. The client should be able to tell from the operation.] Disposition: Closed, no change OMG Issue No: 6111 Title: Reentrancy 1 Source: Kabira Technologies, Inc. (Mr. Conrad Bock, conrad.bock@nist.gov) Summary: How is the effect if isReentrant achieved for actions other than call actions? isReentrant is only on behaviors. Perhaps it should also be available on actions and operations Discussion: The notion of reentrant behavior was introduced by the new activity model but is completely unclear. A resolution of this issue has to await further clarification of the activity view of reentrancy. This issue should be resolved in a manner consistent with activities, if possible. Disposition: Defer Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: ,cb,,cs, Proposals for ballot 12 (April 14) Date: Wed, 14 Apr 2004 09:04:51 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Thomas, Bran, One more request on ballot 12: issue 6111 says reentrancy is "completely" unclear, even though a semantics is given for it in activity in terms of when actions can execute. Would like the first sentence of the resolution removed. Thanks, Conrad Reply-To: From: "Conrad Bock" To: Subject: RE: DRAFT of ballot 12 Date: Fri, 16 Apr 2004 13:56:49 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Thomas, Bran, This is a another request to remove the first sentence of the proposed resolution to issue 6111 in ballot 12. There is a semantics defined for reentrancy in activities, so the statement is incorrect, and as stated is just an opinion. The second sentence is plenty to justify deferral. If the first sentence cannot be removed, then I would like the issue taken from the ballot for further discussion. Thanks, Conrad From: "Thomas Weigert" To: , Subject: RE: DRAFT of ballot 12 Date: Fri, 16 Apr 2004 13:30:45 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal I assume you are referring to the sentence "The notion of reentrant behavior was introduced by the new activity model but is completely unclear." Of course, we can remove this sentence. I apologize, this really should not have stayed in for the final text. Thanks for catching that. Language like this is fine for our internal discussion, but not for a public issued text. Personally, I think we need to get this clearer, but I think that is a bigger job and best deferred. So sorry for the slip. Bran, can you delete the above sentence from the resolution? Thanks, Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Friday, April 16, 2004 12:57 PM > To: uml2-superstructure-ftf@omg.org > Subject: RE: DRAFT of ballot 12 > > > > Thomas, Bran, > > This is a another request to remove the first sentence of the proposed > resolution to issue 6111 in ballot 12. There is a semantics defined for > reentrancy in activities, so the statement is incorrect, and as stated > is just an opinion. The second sentence is plenty to justify deferral. > > If the first sentence cannot be removed, then I would like the issue > taken from the ballot for further discussion. > > Thanks, > Reply-To: From: "Conrad Bock" To: Subject: Issue 6111 (Reentrancy) in Ballot 8 Date: Thu, 2 Jul 2009 18:03:52 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acn7YPv1IVMPIDwCTNmkE8IhSYo6Zw== X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n62M3vQb008204 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1247177048.48676@RaYZXt/uXcXljVuZR1V6cQ X-Spam-Status: No Maged, et al, As long as we're making last minute corrections, issue 6111 (Reentrancy 1) should have the text below appended to the Revised Text section. This was just missed in the update. Conrad In Activities, Parameter: Constraints, remove [3] ("Reentrant behaviors cannot have stream parameters") Semantics, third to last paragraph (the one starting "The execution rules above"), remove the last sentenece (the one starting "A reentrant behavior cannot have"). CallBehaviorAction (as specialized): Constraints, add constraint: [] The called behavior cannot have streaming parameters when isLocallyReentrant is true. CallOperationAction (as specialized): Constraints, add constraint: [] The called operation cannot have streaming parameters when isLocallyReentrant is true. Date: Thu, 02 Jul 2009 19:21:21 -0400 From: "Chonoles, Michael J" Subject: RE: Issue 6111 (Reentrancy) in Ballot 8 To: conrad.bock@nist.gov, uml2-rtf@omg.org Thread-Topic: Issue 6111 (Reentrancy) in Ballot 8 Thread-Index: Acn7YPv1IVMPIDwCTNmkE8IhSYo6ZwACgNww X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 02 Jul 2009 23:29:44.0462 (UTC) FILETIME=[FB1A62E0:01C9FB6C] Why not streaming output parameters? -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, July 02, 2009 6:04 PM To: uml2-rtf@omg.org Subject: Issue 6111 (Reentrancy) in Ballot 8 Maged, et al, As long as we're making last minute corrections, issue 6111 (Reentrancy 1) should have the text below appended to the Revised Text section. This was just missed in the update. Conrad In Activities, Parameter: Constraints, remove [3] ("Reentrant behaviors cannot have stream parameters") Semantics, third to last paragraph (the one starting "The execution rules above"), remove the last sentenece (the one starting "A reentrant behavior cannot have"). CallBehaviorAction (as specialized): Constraints, add constraint: [] The called behavior cannot have streaming parameters when isLocallyReentrant is true. CallOperationAction (as specialized): Constraints, add constraint: [] The called operation cannot have streaming parameters when isLocallyReentrant is true. Reply-To: From: "Conrad Bock" To: Subject: RE: Issue 6111 (Reentrancy) in Ballot 8 Date: Thu, 2 Jul 2009 21:32:04 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acn7YPv1IVMPIDwCTNmkE8IhSYo6ZwACgNwwAASsMmA= X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n631W9xd027061 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1247189536.83524@XrDfn8bm9tt1u6CIfoj6nQ X-Spam-Status: No Michael, > Why not streaming output parameters? This would be a different issue, that the current constraint is too strong (could you file it?). The addition I proposed just updated the current constraint for the correction to reentrancy. Conrad Subject: Re: Issue 6111 (Reentrancy) in Ballot 8 To: Cc: uml2-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Maged Elaasar Date: Fri, 3 Jul 2009 10:25:53 -0400 X-MIMETrack: Serialize by Router on D25ML03/25/M/IBM(Release 8.0.1|February 07, 2008) at 07/03/2009 10:25:56 Conrad, the last change can pass as editorial. This one looks more involving, what do you think? Maged Elaasar, PhD Candidate Senior Software Engineer, Rational Modeling Tools IBM Representative@OMG, CAS Research Staff Member IBM Canada, Ottawa Lab, +1 613 270 4651 "Conrad Bock" "Conrad Bock" 07/02/2009 06:03 PM Please respond to To cc Subject Issue 6111 (Reentrancy) in Ballot 8 Maged, et al, As long as we're making last minute corrections, issue 6111 (Reentrancy 1) should have the text below appended to the Revised Text section. This was just missed in the update. Conrad In Activities, Parameter: Constraints, remove [3] ("Reentrant behaviors cannot have stream parameters") Semantics, third to last paragraph (the one starting "The execution rules above"), remove the last sentenece (the one starting "A reentrant behavior cannot have"). CallBehaviorAction (as specialized): Constraints, add constraint: [] The called behavior cannot have streaming parameters when isLocallyReentrant is true. CallOperationAction (as specialized): Constraints, add constraint: [] The called operation cannot have streaming parameters when isLocallyReentrant is true. pic18982.gif Reply-To: From: "Conrad Bock" To: Subject: RE: Issue 6111 (Reentrancy) in Ballot 8 Date: Fri, 3 Jul 2009 10:38:33 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acn76j4gEL7pt3zwTBKyzYkMDDlvewAAPFbg X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n63Ecc83031199 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1247236723.76893@r3WaNGGCvB0s/bD0lhAQTw X-Spam-Status: No Maged, > the last change can pass as editorial. This one looks more involving, > what do you think? It's not editorial, but also just a portion missed in the original revised text that should have been included. If people would rather not accept the proposed addition, we can leave the revised text as is, and file another issue to finish this one next time. Conrad > Conrad