So, with a little help from my vfr friends, I was able to solve the
referenced problem. For what its worth, here's what I did wrong, why I
did it and how I fixed it:
My application allows some number of UDP ports to be configured to
receive data. The incoming data is expected to begin with a sequence of
characters that constitute an identifier. When data arrives at a port,
the event driven code extracts the 1st group of characters and uses it
as the name of a global variable which it then sets to the value of
entire input string.
This works perfectly until an input error occurs and the code attempts
to use an illegal variable name. In order to prevent this from stopping
the application, I passed the variable name and the intended value to a
function that contained nothing but a "Set" object. Using a function in
this manner allowed trapping "bad variable name" errors in the event
service code. Unfortunately, I only provided one function for all the
UDP input event threads to share. Apparently, given a few hours, this
led to a "race" condition which stopped many (but not all) of the
application threads. Everything looked fine but very little was being done.
I fixed the situation by providing a separate "Set" function for each of
the UDP input event threads. The application has been running for two
days now without a problem - about 10 msgs per second spread over 3 UDP
ports.
I'm somewhat of a slow learner - I've made this same mistake in the
past. It comes from believing what I've read about functions running to
conclusion once they have been called. Apparently event driven functions
don't work this way - it appears that you don't want to allow event
driven code to share functions with any other threads; primary
application threads or other event code threads.
Barrie
whoi
---
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".
referenced problem. For what its worth, here's what I did wrong, why I
did it and how I fixed it:
My application allows some number of UDP ports to be configured to
receive data. The incoming data is expected to begin with a sequence of
characters that constitute an identifier. When data arrives at a port,
the event driven code extracts the 1st group of characters and uses it
as the name of a global variable which it then sets to the value of
entire input string.
This works perfectly until an input error occurs and the code attempts
to use an illegal variable name. In order to prevent this from stopping
the application, I passed the variable name and the intended value to a
function that contained nothing but a "Set" object. Using a function in
this manner allowed trapping "bad variable name" errors in the event
service code. Unfortunately, I only provided one function for all the
UDP input event threads to share. Apparently, given a few hours, this
led to a "race" condition which stopped many (but not all) of the
application threads. Everything looked fine but very little was being done.
I fixed the situation by providing a separate "Set" function for each of
the UDP input event threads. The application has been running for two
days now without a problem - about 10 msgs per second spread over 3 UDP
ports.
I'm somewhat of a slow learner - I've made this same mistake in the
past. It comes from believing what I've read about functions running to
conclusion once they have been called. Apparently event driven functions
don't work this way - it appears that you don't want to allow event
driven code to share functions with any other threads; primary
application threads or other event code threads.
Barrie
whoi
---
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".
That could be very tough to figure out. Trying the simple explanations
first,
time. Also, try using Process View (the real one, not my VEE imitation) on
the VEE process and see what it says about how many Win32 threads are owned
by VEE and what kind of activity it's showing. AFAIK VEE uses 4 or 5 Win32
threads.
I ran across one VEE program that started spending all it's time in the
kernel. Turns out there was a funky device driver. Another situation showed
insane thread count, also not VEE's fault. It's hard to pin it down for any
particular hardware/software combination, but if any process owns somewhere
around 100 Win32 threads then it spends most of it's time thread context
switching and not much time running threads. At least that was the old
advice with sub-G processor speeds. Still, more than a couple dozen threads
is kind of insane unless there's a good reason for it.
Another common problem is deadlock. Are there VEE threads that are waiting
for some mutex or semaphore variable or file to be released, but these
objects are already owned by other threads that are also waiting on their
release, not knowing they already own them? Are the signal objects (variable
or file or what-have-you) being handled ok?
Given that resources don't seem to be a problem, some kind of logic
malfunction (i.e. deadlock) is a likely candidate if user code is executing
normally.
-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".