<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"><META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.45"><TITLE>Re: [vrf] Strange Thread Flow Example.vee</TITLE></HEAD><BODY><P><FONT SIZE=2>I took the habit over the time to put a 1mS delay at the beginning of each parallel thread I create to avoid this kind of problem that were happening some times.</FONT></P><P><FONT SIZE=2>-----Message d'origine-----</FONT><BR><FONT SIZE=2>De: HILTON,GRAEME (A-England,ex1) [<A HREF="mailto:graeme_hilton@agilent.com">mailto:graeme_hilton@agilent.com</A>]</FONT><BR><FONT SIZE=2>Date: 16 mai 2003 11:52</FONT></P><P><FONT SIZE=2>Hi Barrie,</FONT><BR><FONT SIZE=2>You could try have a Main with only two userobjects. The first contains your initialisation routines and the second, the rest of the program.</FONT></P><BR><P><FONT SIZE=2>-----Original Message-----</FONT><BR><FONT SIZE=2>From: Barrie Walden [<A HREF="mailto:bwalden@whoi.edu">mailto:bwalden@whoi.edu</A>]</FONT><BR><FONT SIZE=2>Sent: 16 May 2003 16:43</FONT></P><P><FONT SIZE=2>I use a lot of independent threads and routinely have variable</FONT><BR><FONT SIZE=2>initialization problems due to the order in which they start. Initially</FONT><BR><FONT SIZE=2>I tried using the left-right, top-bottom position technique but had</FONT><BR><FONT SIZE=2>enough self imposed difficulties to cause me to switch over to an</FONT><BR><FONT SIZE=2>"initialization flag" with associated test code at the beginning of each</FONT><BR><FONT SIZE=2>thread. Even this wasn't enough - now I precede the test code with a</FONT><BR><FONT SIZE=2>delay to make sure the initialization flag has been set. It would be</FONT><BR><FONT SIZE=2>nice to have a means for forcing a particular thread to run first and to</FONT><BR><FONT SIZE=2>completion before any other threads start.</FONT></P><BR><P><FONT SIZE=2>-----Message d'origine-----</FONT><BR><FONT SIZE=2>De: Andrew Fudge [<A HREF="mailto:AndrewF@genesysibs.com">mailto:AndrewF@genesysibs.com</A>]</FONT><BR><FONT SIZE=2>Date: 16 mai 2003 04:34</FONT></P><P><FONT SIZE=2>I have noticed some strange thread flow behaviour. If anyone is bored you can play with this.</FONT></P><P><FONT SIZE=2>Step through this program and you can see that "UserFunction2" holds up execution of all other threads. Nothing else can run.</FONT></P><P><FONT SIZE=2>However, if "UserFunction2" sequence input pin is connected to the "Delay" or "Until Break" objects, all threads run as expected.</FONT></P><P><FONT SIZE=2>Could anyone at Agilent explain this behaviour. Are there any priorities on which thread runs first?</FONT></P><P><FONT SIZE=2>Strange...</FONT></P>---<BR>You are currently subscribed to vrf as: rsb@soco.agilent.com<BR>To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".<BR>To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".<BR>To send messages to this mailing list, email "vrf@it.lists.it.agilent.com". <BR>If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".</BODY></HTML>
I don't think that execution order based on block position is guaranteed. Any time I need to guarantee execution order I use sequence lines. Most of the time data flow takes care of sequencing, so don't overuse the sequence lines, but there are some times
when they are necessary. Typical examples are variable initialization and passing data to control input pins.
Even if position related execution order is consistent behavior I wouldn't want to rely on it in the face of future enhancements to a program by me or by somebody else who might move the blocks around. Also Agilent could break the link in a future
release. After all, the execution sequencer doesn't need to know anything about the physical positions of the blocks in order to operate as documented; it's probably just the order in which some internal list happens to be generated.
Regards,
--
Bill Ossmann
Philips Ultrasound
e-mail: bill.ossmann@philips.com
To: "VEE vrf" <vrf@it.lists.it.agilent.com>
cc: (bcc: Bill Ossmann/ANR/MS/PHILIPS)
Subject: [vrf] Re: Strange Thread Flow Example.vee
"Michael Asbery" Classification:
<Michael.Asbery@nrl.navy.
mil>
05/16/2003 08:28 AM
Please respond to
"Michael Asbery"
Andrew,
As Georg points out, running each thread independently would work. The actual object priority, is that Vee executes objects left to right, top to bottom. Thus to get a particular thread to fire first, begin the thread in the Left, Top corner of your
program. I take advantage of this by putting my initialize variables threads in this location so that I can be assured everything is initialized before I start using them later in the program.
Mike
***********************************************************
Michael N. Asbery, NRL Code 5733.20, (202)404-3014, DSN 754-3014
michael.asbery@nrl.navy.mil fax (202)404-7661
***********************************************************
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
R&D could try to maintain the current (undocumented) behaviour while working on new VEE features or fixing defects, at least if they knew customers depended on it. But there could be cases where it's a necessity to change the behaviour in order to add the feature or fix.
If that happened, you might find it very difficult to get your program working again in the new revision, and we might not be able to help you much.
P 67 of the English version of the User's Guide actually mentions: "Propagation through a program is _not_ determined by the geographic locations of the objects in the program...". So although it has been observed by some that in many cases threads that start in the northwest corner seem to begin execution first, it's probably not consistent. And it's not guaranteed that they'll complete execution before other threads do.
When in doubt, use Sequence to enforce execution order. When not in doubt, let data flow work to your advantage, and leave out the sequence connections.
Regards to all,
Scott Bayes
Software Technical Support
Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537
970 679 3799 Tel
970 635 6867 Fax
> -----Original Message-----
> From: bill.ossmann@philips.com [mailto:bill.ossmann@philips.com]
> Sent: Friday, May 16, 2003 7:50 AM
> To: VEE vrf
> Subject: [vrf] Re: Strange Thread Flow Example.vee
>
>
> Mike,
>
> I don't think that execution order based on block position is
> guaranteed. Any time I need to guarantee execution order I
> use sequence lines. Most of the time data flow takes care of
> sequencing, so don't overuse the sequence lines, but there
> are some times
> when they are necessary. Typical examples are variable
> initialization and passing data to control input pins.
>
> Even if position related execution order is consistent
> behavior I wouldn't want to rely on it in the face of future
> enhancements to a program by me or by somebody else who might
> move the blocks around. Also Agilent could break the link in a future
> release. After all, the execution sequencer doesn't need to
> know anything about the physical positions of the blocks in
> order to operate as documented; it's probably just the order
> in which some internal list happens to be generated.
>
> Regards,
> --
> Bill Ossmann
> Philips Ultrasound
> e-mail: bill.ossmann@philips.com
>
>
>
>
> To:
> "VEE vrf" <vrf@it.lists.it.agilent.com>
> cc:
> (bcc: Bill Ossmann/ANR/MS/PHILIPS)
> Subject:
> [vrf] Re: Strange Thread Flow Example.vee
>
> "Michael Asbery" Classification:
> <Michael.Asbery@nrl.navy.
> mil>
>
> 05/16/2003 08:28 AM
> Please respond to
> "Michael Asbery"
>
>
>
>
>
>
> Andrew,
>
> As Georg points out, running each thread independently would
> work. The actual object priority, is that Vee executes
> objects left to right, top to bottom. Thus to get a
> particular thread to fire first, begin the thread in the
> Left, Top corner of your
> program. I take advantage of this by putting my initialize
> variables threads in this location so that I can be assured
> everything is initialized before I start using them later in
> the program.
>
> Mike
>
>
> ***********************************************************
> Michael N. Asbery, NRL Code 5733.20, (202)404-3014, DSN 754-3014
> michael.asbery@nrl.navy.mil fax (202)404-7661
> ***********************************************************
>
>
>
>
> ---
> You are currently subscribed to vrf as: scott_bayes@agilent.com
> To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
> To unsubscribe send a blank email to
> "leave-vrf@it.lists.it.agilent.com".
> To send messages to this mailing list, email
> "vrf@it.lists.it.agilent.com".
> If you need help with the mailing list send a message to
> "owner-vrf@it.lists.it.agilent.com".
>
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
I use a lot of independent threads and routinely have variable
initialization problems due to the order in which they start. Initially
I tried using the left-right, top-bottom position technique but had
enough self imposed difficulties to cause me to switch over to an
"initialization flag" with associated test code at the beginning of each
thread. Even this wasn't enough - now I precede the test code with a
delay to make sure the initialization flag has been set. It would be
nice to have a means for forcing a particular thread to run first and to
completion before any other threads start.
Barrie
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
You could try have a Main with only two userobjects. The first contains your initialisation routines and the second, the rest of the program.
--
Graeme Hilton
-----Original Message-----
From: Barrie Walden [mailto:bwalden@whoi.edu]
Sent: 16 May 2003 16:43
To: VEE vrf
Subject: [vrf] Re: Strange Thread Flow Example.vee
All,
I use a lot of independent threads and routinely have variable
initialization problems due to the order in which they start. Initially
I tried using the left-right, top-bottom position technique but had
enough self imposed difficulties to cause me to switch over to an
"initialization flag" with associated test code at the beginning of each
thread. Even this wasn't enough - now I precede the test code with a
delay to make sure the initialization flag has been set. It would be
nice to have a means for forcing a particular thread to run first and to
completion before any other threads start.
Barrie
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".