OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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.  
>-----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)
>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 
>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
>Research Fellow
>SAP Research Centre Brisbane
>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]