AnsweredAssumed Answered

vrf Event servicing

Question asked by bwalden on Jul 28, 2005

Like • Show 0 Likes0
Comment • 3

Shawn,

Thanks for the explanation - it was good to have my suspicions
confirmed. From my experience, it seems that servicing events from
multiple sources using some fairly complex code can be done with little
problem provided the event code does not use common User Functions (in
fact, it shouldn't use User Functions also found in the application's
non-event code.

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@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

3 Replies

bwalden Jul 26, 2005 9:29 PM
Mark Correct
Correct Answer
Hi folks,

Those of you that have been reading the reflector messages for a lengthy
time may remember that I have had code "race" problems on a number of
occasions. The symptom has been major sections of my application simply
stopping without error notification and the cause has always been
related to the need for multiple I/O event service routines.

The accepted solution has been to revise my event code so that it does
the absolute minimum (store the incoming data, set a flag, and exit),
leaving the complicated work for a single thread that monitors the
various flags. Unfortunately, this has always been easier said than done
and recently I have run into a situation where speed issues made complex
event code the only solution. Interestingly enough, it hasn't turned out
to be a problem despite the fact that the application has been servicing
1 second events for well over a month.

This got me to thinking about why my new service code works and some of
my previous attempts didn't. One possibility I can think of is that code
race problems only occur if "user functions" are included in the event
service loops; built-in functions and all the normal Vee objects can be
used without difficulty. To the best of my knowledge, multiple use of
the same user function has always been involved in my previous problems.
In at least one instance, the solution was to replace the user function
with a copy of its code "in-line".

Does anyone know if there is something about calls to user functions
that would allow race problems when calls to built-in functions prevent
them?

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@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 Jul 27, 2005 1:40 AM
Mark Correct
Correct Answer
> Does anyone know if there is
> something about calls to user
> functions that would allow
> race problems when calls to
> built-in functions prevent
> them?

Yes. It's a common problem most often (and most probably) known as
re-entrancy. If you're aware of the problem, feel free to skip this...

The difference between a built in function and a User Function is that the
built in functions are either: 1) wrappers for CRT or Windows functions or
at least 2) compiled. A User Function is defined in terms of the VEE
execution engine. There is a ton of housekeeping that goes along with every
VEE object and every statement inside of every VEE Formula in a VEE User
Function. In addition there's the call itself - calling a VEE User Function
is probably a very heavy weight operation in terms of preparation. Even
calling an external compiled function is heavy weight when compared to
machine language. All this extra work means more opportunity for
unintentional re-entrancy.

Re-entrancy happens when one or more threads re-enter the same code at the
same time. VEE is not re-entrant by definition (I'm not sure why, but as far
as I can gather it is not primarily stack-based. Stack-based languages are
almost immune to the problem). One example is recursion. VEE cannot do
recursion - a VEE User Function cannot call itself. Another example is
multithreading. Two separate VEE threads cannot execute the same VEE User
Function "at the same time". VEE handles this condition on it's own though.

A third and much more subtle example is VEE User Functions that service
ActiveX Events (or, I assume, dotNET Events). We have been taught to believe
that an Event service function runs to completion regardless of VEE
thread-switching. However, it seems that if VEE User Functions are called in
the event service function this may not be the case. I have one example that
clearly demonstrates this. The example may be artificially indicating this
though. It also involves subclassing.

Also, if VEE is not done executing an Event processor and another Event
fires that requires service, it's not entirely clear to me that these Events
are "serialized" - executed one after the other. Especially when external
User Functions are involved. Most ActiveX Event generators are "apartment
threaded", a pseudo multithreading safe technique that Microsoft came up
with. I'm not sure that VEE can remain "inside the apartment" and hence can
remain thread-safe.

These issues are only complex from the point of view of High Level
Languages. I've recently discovered that not even Visual Basic is thread
safe (that little fact surprised the heck out of me). When you drop down to
C all these problems vanish except for the static storage class, globals and
some other possible dll issues.

If you're starting to run into this, probably the best plan is to re-examine
the VEE options. I can't remember exactly what your situation is (and I'm
too lazy to go look it up but maybe there's a way to drop all other
software out of the equation leaving only VEE (besides instrument drivers of
course). If you get stuck on that front, don't discount SICL. It can do some
amazing things - some of which can be made to work with VEE. If those
options won't work out, SICL still works *very* well with C.

If you do get stuck falling all the way back to C, imagine a dll that's your
event service front end with VEE doing the data processing. Let C handle the
events and buffer the data, let VEE process the data at it's own pace in
it's own way. It can sometimes be a beautiful thing that makes the
impossible possible.
-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 Jul 27, 2005 7:22 AM
Mark Correct
Correct Answer
Barrie,

I wanted to make sure I wasn't talking out my rear on that whole
event-apartment sphiel so I did some further checking. By default, a VB 6
ActiveX DLL project is marked for "MultiUse". This is where the Apartment
threading comes from. That's mainly the part I wanted to check on, and I
found an article that addresses the question of race, deadlock or (as MS
says), "blocked execution".

The initial article is here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/htm
l/vbconinstancingforolecomponentclasses.asp
(one line)

Search for the word "apartment". The other article mentioned, Building Code
Components, contains a great deal of information about exactly how events
are handled in the various ole models:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/htm
l/vbconbuildingcodecomponents.asp
(one line)

This last article can do a whole lot more to explain the problem than I can.
-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

vrf Event servicing

Outcomes

Related Content

Recommended Content