Hi Andrew,
What is needed is the PAR construct: I do not believe any combination of
channels can do the same exactly. If C starts after (A|B) finish, etc, then
the occam pseudocode (which I hope is self-explanatory) is:
SEQ
PAR
A
B
--END PAR
C
PAR
D
E
--END PAR
F
If you want to start them all at the same time it would require some
channels to make them end in order:
PAR
SEQ
PAR
SEQ
PAR
A
B
--END PAR
communicate to C
C (communicate from AB)
--END PAR
communicate to D
communicate to E
SEQ
PAR
D (communicate from ABC)
E (communicate from ABC)
--END PAR
communicate to F
F (communicate from DE)
--END PAR
A PAR requires the parent store two words (its --END PAR resumption
instruction address and n-1 where n is the number of children) and start
(i.e. schedule) n-1 child tasklets (and branch to the n-th). Each child must
terminate with an 'endp' which checks the second word. If it is >0 it
decrements it and abandons its instruction stream. If it is 0 it branches to
the parent's resumption address.
Larry
On 10/22/08, Andrew Francis <[EMAIL PROTECTED]> wrote:
>
> Larry:
>
> >Do you mean C starts after (A|B) finish, or they all start together, or
> >..?
>
> Why did I write that in 2005?
>
> Yes C should start after A AND B finish. However the way the code is
> written, tasklets actually start before they block on channels.
>
> The point of that example was it was *very* easy to create a deadlock
> scenario with a relatively simple precedent graph implemented with just
> channels.
>
> Cheers,
> Andrew
>
>
>
>
>
>
> --- On Tue, 10/21/08, Larry Dickson <[EMAIL PROTECTED]> wrote:
>
> > From: Larry Dickson <[EMAIL PROTECTED]>
> > Subject: Re: [Stackless] Stackless based replacement
> > To: [EMAIL PROTECTED]
> > Cc: [email protected]
> > Date: Tuesday, October 21, 2008, 9:46 AM
> > Hi Andrew,
> >
> > I read your 2005 note, and I do not understand
> >
> > >I expect the following execution trace
> > >
> > >(A | B) C (D | E) F
> > >
> > >|* - means processes can execute in parallel.
> > *>
> > >It is okay to see B finish before A. However it is
> > >wrong to see C finish before B and A finish.
> >
> > Do you mean C starts after (A|B) finish, or they all start
> > together, or ..?
> >
> > Larry
> >
> > On 10/21/08, Andrew Francis <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > Hi Larry:
> > >
> > > > We seem to have different ideas of what is
> > simple. You
> > > > propose exceptions, waits, signals, barriers,
> > re-initialization,
> > > > and presumably global signal values. This in my
> > opinion is a whole
> > > >Italian restaurant of spaghetti, and it sounds
> > intrinsically global, >which
> > > is poison to maintainable multiprocessing in my
> > experience.
> > >
> > > This is what I had in mind. A sketch.
> > >
> > > def producer(synchronizer):
> > > try:
> > > # do some computation
> > > synchronizer.signal(result)
> > > except Signalled, data
> > > # oops the consumer has moved on.... maybe
> > > # I should gracefully terminate.....
> > >
> > >
> > > def consumer(synchronizer):
> > > output = synchronizer.wait()
> > > # okay, let us do some stuff with the output
> > >
> > > synchronizer = Synchronizer(numberOfProducers)
> > > stackless.tasklet(consumer)(synchronizer)
> > > for .... :
> > > stackless.tasklet(producer)(synchronizer)
> > >
> > > Most of the effort is in defining the right
> > behaviour.....
> > >
> > > Once again, my experiences are when you naively use
> > channels, it is easy to
> > > get in trouble. A construct like receive_first()
> > looks difficult to
> > > implement, in comparison to a synchronizer.
> > >
> > > Here is a thread from December 2005 (2005!)
> > >
> > >
> > http://www.stackless.com/pipermail/stackless/2005-December/000290.html
> > >
> > > Cheers,
> > > Andrew
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
