[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: WG: [wsbpel] Issue 189: Eliminate JoinConditions alwaysevaluatingonly after all source activities are complete
Marlon - I am not convinced by one of your basic premises, and subsequently, I don't think there's an issue here. You claim that the existence of a control link from A1 to A3 implies that there is a control dependency between A1 and A3's enclosing Sw. In the case where C1 evaluates to true, no such control dependency exists. I posit that this issue of "synchronization for garbage token collection" is a red herring. Danny van der Rijn Trickovic, Ivana wrote: >This message from Marlon Dumas did not reach the TC mailing list (because Marlon is still not a member of the TC). So, I am forwarding it to the list. > >Regards, > >Ivana > >-----Ursprüngliche Nachricht----- >Von: Marlon Dumas [mailto:m.dumas@qut.edu.au] >Gesendet: Dienstag, 15. Februar 2005 10:04 >An: wsbpel@lists.oasis-open.org >Cc: Rania Khalaf; ygoland@bea.com; dannyv@tibco.com; Trickovic, Ivana >Betreff: [wsbpel] Issue 189: Eliminate JoinConditions always evaluatingonly after all source activities are complete > > >I would like to point out that the question of "short-circuited >evaluation of join conditions" raised by issue 189 is related to another >question that has not yet been considered and that I would like to term: >"synchronization for garbage token collection". To introduce and >illustrate this latter question, consider the following example (I use a >pseudo-BPEL notation to avoid cluttering the presentation with >unnecessary details): > ><flow name="F"> >A1 (activity A1 is source of a link named l1) > ><sequence name="Seq"> ><switch name="Sw"> > case C1: A2 > case C2: A3 (activity A3 is target of link l1) ></switch> > >A4 ></sequence> > ></flow> > >Let's assume that the flow activity F starts, thereby starting >activities A1, Seq, and Sw. Now, let's assume that condition C1 >evaluates to true, thereby starting activity A2. Now assume that >activity A2 completes (but A1 is still ongoing). The question is: Should >activity Sw be considered to be completed at this point (which would >result in activity A4 being started), or should we wait until link l1 is >determined so that the join condition defined at A3 can be evaluated? >(Note that the evaluation of the join condition at A3 is irrelevant, >since the branch of the switch in which A3 is located was not chosen and >thus A3 is not executed and negative tokens are thrown along any links >leaving A3). If the answer to this question is that Sw is considered to >be completed, and thus A4 is started, then we see that A4 can be >executed even though A1 has not completed, which contradicts the >principle that "a control-link implies a control dependency". > >Generally speaking, it is important to note that a switch activity Sw, >such that there is a link leading to a sub-activity of Sw (whether a >direct sub-activity of Sw, or a sub-activity nested deep inside Sw), >potentially implies a garbage collection of the true/false token that >will transit through this link. The question is: "Should this garbage >token collection be completed before the switch activity is considered >to be completed?" I term this question "synchronization for garbage >token collection". > >The question of synchronization for garbage token collection is related >to that of short-circuited evaluation of join conditions. Indeed, if we >follow the principle that "a control link implies a control dependency", >then: (i) short-circuited evaluation of join conditions is NOT possible; >and (ii) all "garbage tokens" that are expected to transit through links >leading into branches of a switch or pick that are not taken (or into >scopes that have been halted due to an event or fault), must be >collected before the switch/pick/scope activity is considered to be >completed. In the example above, this second condition would prevent A4 >from being started before A1 has completed. > >On the other hand, if it is decided that "a control-link does not imply >a control dependency", then the space of design choices is open and four >alternative design choices are possible depending on the answers to the >two questions: (i) is short-circuited evaluation of join conditions >allowed (yes or no)? and (ii) should synchronization for garbage token >collection always occur (yes or no)? (Note that since links are not >allowed to cross the boundaries of serializable scopes and loops, the >question of garbage token collection does not apply to them). > >These considerations illustrate the importance of carefully answering >the question: "Do control links imply control-flow dependencies?" The >implications of a negative answer to this question are more far-reaching >than just allowing for short-circuited evaluation of join-conditions, >which was the primary focus of the discussions leading to issue 189. > >Also, issue 189 may have strong impact on the following sentence of the >current spec: > >12.5.1. Link Semantics >"If, during the performance of structured activity S, the semantics of S >dictate that activity X nested within S will not be performed as part of >the behavior of S, then the status of all outgoing links from X is set >to negative. An example is an activity within a branch that is not taken >in a switch activity, or activities that were not completed in a scope >in which processing was halted due to a fault, including a >bpws:joinFailure." > >A question to be considered here is: Should the status of the outgoing >links from X be set to negative (and thus the activity that is the >target of X possibly allowed to proceed) even though there may be links >whose target is X that have not yet been determined at this point? If >so, this breaks the principle that "a control link implies a control >dependency", since the activities that "precede X" (i.e. they are source >of a link leading to X) may not yet be completed. > >Note that this latter question may need to be treated separately from >the above. > >--- >Marlon Dumas >Senior Lecturer >Queensland University of Technology >m.dumas@qut.edu.au > >Research Fellow >SAP Research Centre Brisbane >marlon.dumas@sap.com > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]