AnsweredAssumed Answered

vrf Multi Threading

Question asked by VRFuser on May 20, 2004

Like • Show 0 Likes0
Comment • 9

> I juss report me eyeballs saw.

Amen. If it works it's right

> Oh, sometimes even pro's make mistakes.
> Ever found errors in your textbooks?

Ah, Herb Schildt. One big, long error

> less multiple processors

And *there's* an interesting question. Does VEE make use of multiple
processors explicitly, or just implicitly?

> I dunno what locks be,

If I had to guess, I'd say it's some kind of reference count similar to COMs
reference count. I suppose it could be used as an indicator of orderly
conduct through source in the interpreter. If it's ever something other than
0 or 1 then it's invalid: either something acquired it and didn't release it
or something released it and didn't acquire it. I don't see it referenced on
the internal debug object properties so it's difficult to say.
-SHAWN-

---
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@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

No one else has this question

Outcomes

9 Replies

VRFuser May 18, 2004 9:17 PM
Mark Correct
Correct Answer
> However when i run my program it seems to only go down
> the drive sequence thread and the other thread does not
> get initiated.

There are a couple issues that could be messing you up. There are two
instances I'm aware of where thread execution is atomic (it doesn't switch
away to another thread): ActiveX event functions and any code called from a
formula if the call was input to the formula via the formula input pin.

Anything called from an event will always execute atomically until the event
exits, and similarly for anything called in that unique way from a formula
object.

A delay *might* be atomic - I don't know. It shouldn't be, but you never
know.

VEE does MT pretty much like anything does (as far as I can see anyway).

There are instrument issues to consider also. I found out about that the
hard way. If you're using the same instrument in two different threads,
define that instrument TWICE with two different names. Use one name for each
thread that uses the instrument. This works for as many as five separate
threads (using five separate definitions in IO Manager) but I've never taken
it beyond that. I assume it would work fine.

This way IO gets muxed as it should and nothing gets mixed up. If you use
the same name in different threads all kinds of strange things can happen
-SHAWN-

---
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@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser May 18, 2004 9:18 PM
Mark Correct
Correct Answer
<!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] Multi Threading</TITLE></HEAD><BODY>I had this sort of problem in the past. I found a fix then and now I apply the fix by default everywhere to avoid the problem. I just put a short delay (1 mSec) at the beginning of each thread. May be this will work for you too.Example: +-------+ | start | +---+---+ | +---+----+ | common | +---+----+ | +-----+------+ | | +---+----+ +---+---+ | 1 mS | | 1 mS | +---+----+ +---+---+ | | +---+----+ +---+----+ | Action | | Action | +---+----+ +---+----+ | | -----Message d'origine----- De: Amrik Sekhon [<A HREF="mailto:amrik.sekhon@geeplus.biz">mailto:amrik.sekhon@geeplus.biz</A>] Date: 19 mai 2004 11:07I need help in using multi threading. I need the two threads to run independantly of each other.I have one thread that controls the drive sequence and is full of delays, so that runs slowly.The other thread is taking the measurements continuously as fast as the software/hardware will allow. There are no delays in this.However when i run my program it seems to only go down the drive sequence thread and the other thread does not get initiated.I am conecting the output sequence pin of the previous command to the input sequence pins of the two seperate threads, is this correct??How do i get the two threads to work independantly???Help!!--- 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@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".</BODY></HTML>
Like • Show 0 Likes0
Actions
VRFuser May 18, 2004 11:47 PM
Mark Correct
Correct Answer
Like • Show 0 Likes0
Actions
amrik.sekhon May 19, 2004 1:07 AM
Mark Correct
Correct Answer
Hi VRF

I need help in using multi threading. I need the two threads to run
independantly of each other.

I have one thread that controls the drive sequence and is full of delays, so
that runs slowly.

The other thread is taking the measurements continuously as fast as the
software/hardware will allow. There are no delays in this.

However when i run my program it seems to only go down the drive sequence
thread and the other thread does not get initiated.

I am conecting the output sequence pin of the previous command to the input
sequence pins of the two seperate threads, is this correct??

How do i get the two threads to work independantly???

Help!!

---
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@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser May 19, 2004 2:10 AM
Mark Correct
Correct Answer
Like • Show 0 Likes0
Actions
VRFuser May 19, 2004 2:11 AM
Mark Correct
Correct Answer
Hi Scott and Nicole,

The new link is very much appreciated! Thanks for getting that implemented. Now
if there was only something you could do about the size of the 71.5MB download!
(I know. It's the penalty we pay for including MATLAB and .NET in VEE. Oh well.)

On a different note, when I tried to install the VEE 7 eval, I ran into a script
error right after clicking on the "Install Agilent VEE Pro Development" button
on the first information screen. I managed to trace it down though. I had placed
the downloaded installation package in the "G:InstallAgilent & HP stuffVEE 7
[eval]" folder and that ended up being the culprit. When I changed the '&' in
the path to 'and', the error went away. Just thought I would point that out,
since the ampersand IS a legal character for a long file or directory name.

Cheers!
Mike Groves

-----Original Message-----
From: BAYES,SCOTT (A-Loveland,ex1) [mailto:scott_bayes@agilent.com]
Sent: Monday, April 19, 2004 1:24 PM
To: VRF
Subject: [vrf] Easy availability of VEE Runtimes

Hello vrf-ers,

Some months ago a number of vrf-ers requested an easier way for your end-users
to get access to the VEE Runtime installers via the web. At that time the
runtimes were available only through the ADN, requiring a registration and
login, then following some links for your end-user to get the installer. You
wanted it to be easier for them.

We were listening.

Nic and the ADN Webmaster went to work and put together a page of easy runtime
downloads for:

VEE 7.0
VEE 6.2
VEE 6.1
VEE 6.01
VEE 5.01

You should send your end-users who need to install VEE Runtimes to <
www.agilent.com/find/veeruntime >, where they will be able to get any of these
runtime downloads very simply and easily. There are readme files there as well,
with short instructions on downloading and installing.

Note that some of the runtimes have different unzip/installation instructions
because they come from different eras. 7.0 is far and away the easiest (a single
file when unzip-ped), but for some of the older ones it may be worthwhile for
you or your end-users to read the readmes.

If your users select any of the other links on that page they may be required to
register or log in to ADN, but for the runtime downloads and readmes there's no
such requirement.

Best Regards,

Scott Bayes (for Nic)
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

---
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@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser May 19, 2004 5:18 PM
Mark Correct
Correct Answer
Not so sure. Saw a single device with multiple names used in 6.1 within a
pretty sound engineering company. Found intermittent errors. Solved the
problem with a single name and controlled flow. When prog had to use same
device in two different threads, set a global that each thread could check.
Then call a third thread that called the device, read/write, to/from string.
Note, to keep the number of globals manageable, place each into a global
record, every prog sees. I try to use only one global, but often a few more
are needed whenever I am not able to pre-define the variable. Worked fine
after that. Activate write whenever write string is NOT empty, read always
and stuff into a read string, or text array, your own defined buffer. Empty
buffer under control, i.e. when there is no read needed. I use 30 ms(0.030
s) or less for the timeout, most times, note you may also read on event,
select timeouts as needed. Act on timeout, i.e. loop control. Also note
that if you do a lot of read before checking buffer, the buffer can be
off-loaded onto the drive.

Essentially what this does is control the interrupts instead of allowing
them to control you.

Rufus

-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: Wednesday, May 19, 2004 1:18 PM
To: VRF
Subject: [vrf] RE: Multi Threading

> However when i run my program it seems to only go down the drive
> sequence thread and the other thread does not get initiated.

There are a couple issues that could be messing you up. There are two
instances I'm aware of where thread execution is atomic (it doesn't switch
away to another thread): ActiveX event functions and any code called from a
formula if the call was input to the formula via the formula input pin.

Anything called from an event will always execute atomically until the event
exits, and similarly for anything called in that unique way from a formula
object.

A delay *might* be atomic - I don't know. It shouldn't be, but you never
know.

VEE does MT pretty much like anything does (as far as I can see anyway).

There are instrument issues to consider also. I found out about that the
hard way. If you're using the same instrument in two different threads,
define that instrument TWICE with two different names. Use one name for each
thread that uses the instrument. This works for as many as five separate
threads (using five separate definitions in IO Manager) but I've never taken
it beyond that. I assume it would work fine.

This way IO gets muxed as it should and nothing gets mixed up. If you use
the same name in different threads all kinds of strange things can happen
-SHAWN-

---
You are currently subscribed to vrf as: rwarren@amti.net 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@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@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser May 19, 2004 5:40 PM
Mark Correct
Correct Answer
> Not so sure.

Oh I am. This advice comes straight from $475/hr. HP FEs. It was a special
situation though and that probably contributed to the solution somehow.
Dozens of serial devices of the same type are accessed by several different
threads serving several different purposes using Direct IO with address
input. When the instrument name is the same and two or more threads happen
to access the same instrument at the same time, there's no exclusion and
everything gets messed up.

> set a global that each thread could check.

Yes. Mutexing. This is exactly what different names accomplished. The caveat
is that each Direct IO object must be a complete thought. This was slightly
more difficult to arrange but kept the VEE program just under the
suitability wire. Full mutexing with an honest-to-goodness Win32 Mutex
object proved pointless as I didn't realize at the time that VEE's execution
thread is it's UI thread and there's only one of them. I thought it would
spawn a thread for each VEE thread. Full mutexing with variables produced
all kinds of object locking problems. I'm not sure exactly what that
terminology is supposed to mean, but the effect is a BRB with "Object lock
count invalid".
-SHAWN-

---
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@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions
VRFuser May 20, 2004 12:50 AM
Mark Correct
Correct Answer
I hear ya. I juss report me eyeballs saw. What happened was a timing
problem occurred, the i/o didn't switch names since it was already used with
another. I dunno ????.... <saw it with single step>

Oh, sometimes even pro's make mistakes. Ever found errors in your
textbooks?

Dunno 'bout the "locks", well behaved threads should not be a problem, since
really, only a single runs at a time, less multiple processors, or a
multi-threaded one. Note that it should not matter since we call only a
single i/o. Also since the i/o is much slower than the processor then som'n
must be wrong if there be "locks", but, I dunno what locks be, so ...

Rufus

-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: Thursday, May 20, 2004 9:40 AM
To: VRF
Subject: [vrf] RE: Multi Threading

> Not so sure.

Oh I am. This advice comes straight from $475/hr. HP FEs. It was a special
situation though and that probably contributed to the solution somehow.
Dozens of serial devices of the same type are accessed by several different
threads serving several different purposes using Direct IO with address
input. When the instrument name is the same and two or more threads happen
to access the same instrument at the same time, there's no exclusion and
everything gets messed up.

> set a global that each thread could check.

Yes. Mutexing. This is exactly what different names accomplished. The caveat
is that each Direct IO object must be a complete thought. This was slightly
more difficult to arrange but kept the VEE program just under the
suitability wire. Full mutexing with an honest-to-goodness Win32 Mutex
object proved pointless as I didn't realize at the time that VEE's execution
thread is it's UI thread and there's only one of them. I thought it would
spawn a thread for each VEE thread. Full mutexing with variables produced
all kinds of object locking problems. I'm not sure exactly what that
terminology is supposed to mean, but the effect is a BRB with "Object lock
count invalid".
-SHAWN-

---
You are currently subscribed to vrf as: rwarren@amti.net 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@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@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Like • Show 0 Likes0
Actions

vrf Multi Threading

Outcomes

Related Content

Recommended Content