On 19 Jun 2009, at 10:38, Stian Soiland-Reyes wrote: > On Fri, Jun 19, 2009 at 06:07, Jan Hidders<[email protected]> > wrote: > >> We are still working on the formal semantics and were not entirely >> sure about the exact semantics of control links. We currently have >> two >> guesses: >> >> If there is a link from processor P to Q then >> 1. Q cannot start any activity >> 2. Q cannot start consuming any of its input >> until P has completely produced its output. >> >> Is it 1 or 2? They are not exactly the same since Q might have some >> parts that already are able to execute without needing any input. > > It's both. > > An iteration cannot start before all the control links are satisfied > AND all the input ports have received a value for that iteration.
Just to be clear: when you say "have received a value" do you mean that they have received a complete value, or that they have received it partially for at least one index? > (This does allow for iteration 4 to start when all it's inputs are > ready, even if iteration 2 and 3 don't have all their inputs yet - > which can occur if upstream processors have multiple threads) > > So it doesn't help that Q have some parts that are ready to start, a > processor consumes the values at each input port at the same time, so > it's like a single function call - in super-pseudocode: > > [c1,c2,c3].wait(); > o1,o2,o3 = f(i1,i2,i3,i4) > > > Also note that 'finished' for the other end of the control link means > that there's no more iterations for that process ID - meaning that > the empty index [] has been returned. So when exactly is the empty index returned? Is this after each iteration has produced its complete output, or after each iteration has completed all its activities? Those moments might not be exactly the same since in principle an iteration might be executing a workflow that might have produced its final output and still have some activities running. > (This means that the full iterations will have to finish in the > controlling processors before the first iteration of the controlled > processor can start) > > For nested workflows this means that nested workflows behave like a > real processor (they are in a real processor) - not as if they were > simply merged with the parent workflow - the same requirement of > synchronous iterations apply to the outputs - so a processor cannot > (should not!) output on portA and portC, but not on portB. Do you just mean to say here that all output ports always produce values, or are you talking about synchronization here, i.e., they produce it more or less at the same moment? -- Jan Hidders ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/ Developers Guide: http://www.mygrid.org.uk/tools/developer-information
