Application freezing while in foreground sporadically

[jmorris]

Greetings. Occasionally my application's front panel will freeze, and not update any of the indicators or notice commands from controls, but only while it is in the foreground. As soon as I click on the desktop or another application, it recovers and works as expected. If I let it stay frozen, one of my two threads (the one that doesn't do any work with the front panel) times out, flags an error, and the thread that does work with the front panel inexplicably catches it and throws up a dialog box, after which things work normally. If I turn off the background thread's timeout, then after a long while (30-60 seconds) it will recover, sometimes just for a second and then going back to being frozen. Any ideas as
to why this might be happening, and what I can do about it? Thanks!

[Greg_McKaskle2]

> Greetings. Occasionally my application's front panel will freeze, and
> not update any of the indicators or notice commands from controls, but
> only while it is in the foreground. As soon as I click on the desktop
> or another application, it recovers and works as expected. If I let
> it stay frozen, one of my two threads (the one that doesn't do any
> work with the front panel) times out, flags an error, and the thread
> that does work with the front panel inexplicably catches it and throws
> up a dialog box, after which things work normally. If I turn off the
> background thread's timeout, then after a long while (30-60 seconds)
> it will recover, sometimes just for a second and then going back to
> being frozen. Any ideas as to why this might be happening, and what I
> can do about it? Thanks!

I have never seen this, and I haven't heard about it for years, but I
think it was when Win2K first came out that similar reports were made.

Our suspicion was that the OS balancing was getting overly ambitious.
The UI of the panel was consuming quite a bit of time and the OS was
trying to make sure that background tasks were still able to run. To
help this, some OSes perform priority leveling, where they will sample
how busy the tasks are and lower the priority of the most active
threads/processes and possibly raise the priority of the least active
tasks. This is one of those low-level highly volatile actions that only
someone working on the OS will know for sure, and they may change
frequently.

We tried numerous times to provoke the behavior and determine what was
causing it. We never really found a smoking gun, and the few reports
that we heard were localized to Win2K, at least that is what I remember.
The reports slowed and stopped, so presumeably MS changed the policy
in a patch or some other affect caused the symptom to go away.

Does any of this sound like it applies? Please give more info about the
OS and what else might be going on in the system. You might also want
to leave the task manager or performance monitor running to see what
states various tasks are in when this occurs.

Greg McKaskle

[Anonymous]

Hi,

I am trying to do what follows: I have a full screen VI with
indicators showing global variables and a handful of
buttons.

Some of these buttons launch modal VIs -so I can't loose
focus on them- in the center of the screen, where the
operator modifies values, which in turn launches an
algorithm in more sub-VIs that modifies said global
variables.

I need to have the indicators refreshed on the main screen
behind in (pseudo) real time. A latency of a couple hundred
milliseconds is OK.

I have read available information in the fine manuals about
validating multithreading and using various threads (MMI,
I/O VIs, others1 and others2), and have followed it, to no
avail: the main screen is not refreshed until after I leave
the modal VI.

I have even affected al
l subVIs called by the modal VI to
the very same thread of execution so it can run fully.

I have tested the software under Win98SE and WINNT4 with the
same results.

I use LV 6.1; from what I understand of the docs, it should
work 8-), but does not. Can anyone please help?

Regards, Robert

[robert_s]

Hi,

I am trying to do what follows: I have a full screen VI with
indicators showing global variables and a handful of
buttons.

Some of these buttons launch modal VIs -so I can't loose
focus on them- in the center of the screen, where the
operator modifies values, which in turn launches an
algorithm in more sub-VIs that modifies said global
variables.

I need to have the indicators refreshed on the main screen
behind in (pseudo) real time. A latency of a couple hundred
milliseconds is OK.

I have read available information in the fine manuals about
validating multithreading and using various threads (MMI,
I/O VIs, others1 and others2), and have followed it, to no
avail: the main screen is not refreshed until after I leave
the modal VI.

I have even affected all su
bVIs called by the modal VI to
the very same thread of execution so it can run fully.

I have tested the software under Win98SE and WINNT4 with the
same results.

I use LV 6.1; from what I understand of the docs, it should
work 8-), but does not. Can anyone please help?

Regards, Robert

[Greg_McKaskle2]

> Some of these buttons launch modal VIs -so I can't loose
> focus on them- in the center of the screen, where the
> operator modifies values, which in turn launches an
> algorithm in more sub-VIs that modifies said global
> variables.
>
> I need to have the indicators refreshed on the main screen
> behind in (pseudo) real time. A latency of a couple hundred
> milliseconds is OK.
>

My guess is that you have a dataflow dependency on your diagram that
requires you to wait for the modal dialog to return before the globals
are read and displayed to the indicator displays.

If you have multiple loops on your main diagram, one reading the globals
and updating the displays with a delay in the loop, and another that
reads the buttons and puts up a modal
dialog depending on the button
state, these while loops can run independently, no matter what you set
the threading settings to. In fact, you are better off leaving those
advanced settings and priorities alone in most cases.

If this doesn't work, please describe your diagram.

Greg McKaskle

[Paul Cardinale]

robert_s wrote in message news:...
> Hi,
>
> I am trying to do what follows: I have a full screen VI with
> indicators showing global variables and a handful of
> buttons.
>
> Some of these buttons launch modal VIs -so I can't loose
> focus on them- in the center of the screen, where the
> operator modifies values, which in turn launches an
> algorithm in more sub-VIs that modifies said global
> variables.
>
> I need to have the indicators refreshed on the main screen
> behind in (pseudo) real time. A latency of a couple hundred
> milliseconds is OK.
>
> I have read available information in the fine manuals about
> validating multithreading and using various threads (MMI,
> I/O VIs, others1
and others2), and have followed it, to no
> avail: the main screen is not refreshed until after I leave
> the modal VI.
>
> I have even affected all subVIs called by the modal VI to
> the very same thread of execution so it can run fully.
>
> I have tested the software under Win98SE and WINNT4 with the
> same results.
>
> I use LV 6.1; from what I understand of the docs, it should
> work 8-), but does not. Can anyone please help?
>
> Regards, Robert

Is the modal VI called from inside an event structure?
If so, open the "Edit Events" dialog for the frame that calls the VI
and make sure that "Lock front panel until the event case for this
event completes" is unchecked.

Paul Cardinale

[Anonymous]

On 26 Nov 2003 07:13:31 -0800, Paul Cardinale wrote on Re:
Multithreading issue:

>Is the modal VI called from inside an event structure?

No it is not.

>If so, open the "Edit Events" dialog for the frame that calls the VI
>and make sure that "Lock front panel until the event case for this
>event completes" is unchecked.

I have built a simplified version of what I want to do, but
it does not work as expected: full screen VI A has an
indicator that displays global variable V, and a button that
launches modal VI B. In VI B, a command modifies global
variable V. VI B's window is centered on the screen, but the
indicator in VI A is visible. When modifying variable V from
VI B, nothing happens on VI A' indicator until after I close
VI B. Obviously
this is not what I want to do...

I tried to remove VI B's "modality" but this does make the
problem disappear.

[robert_s]

On Wed, 26 Nov 2003 15:05:52 GMT, Greg McKaskle wrote on Re:
Multithreading issue:

>> Some of these buttons launch modal VIs -so I can't loose
>> focus on them- in the center of the screen, where the
>> operator modifies values, which in turn launches an
>> algorithm in more sub-VIs that modifies said global
>> variables.
>>
>> I need to have the indicators refreshed on the main screen
>> behind in (pseudo) real time. A latency of a couple hundred
>> milliseconds is OK.
>>
>
>My guess is that you have a dataflow dependency on your diagram that
>requires you to wait for the modal dialog to return before the globals
>are read and displayed to the indicator displays.

As I just explained in a previous message, a simplified
version of what I want
to do does not work either; I am
pretty sure there is no dataflow congestion: just one global
variable read from one VI and written to in the other...
Unless this can be considered as a dataflow dependency...

>If this doesn't work, please describe your diagram.

I'll publish it on my web site and let you know the URL.
Thanks for your help!

[robert_s]

This may help some....

On Wed, 26 Nov 2003 23:50:22 +0100, robert_s wrote on Re:
Multithreading issue:

A couple of days ago, I wrote about a goal I need to achieve
in programming a rack for radar transponders:

>I have built a simplified version of what I want to do, but
>it does not work as expected: full screen VI A has an
>indicator that displays global variable V, and a button that
>launches modal VI B. In VI B, a command modifies global
>variable V. VI B's window is centered on the screen, but the
>indicator in VI A is visible. When modifying variable V from
>VI B, nothing happens on VI A' indicator until after I close
>VI B. Obviously this is not what I want to do...
>
>I tried to remove VI B's "modality" but this does make the
>problem disappear.

After carefully reading the docs, I ran many tests in order
to have two VIs, one caled by the other, to multitask
gracefully. As I said above, I never could make this happen,
particurlarly by enabling multithreading, affecting
different threads of execution to each VIs, playing on
execution priority, etc.

A friend who by profession is much more proficient with LV
than I am gave me the solution, and here it is:

VI A the caller should have two While loops, with a "WAit"
function of say 100ms; one loop is in charge of continuously
displaying global variable V on the indicator, the other of
calling VI B.

VI B itself consists of a while loop where a command feeds
and modifies global variable V. B is modal and centered, so
it won't hide the indicator on A.

This indicator is correctly updated on A when V is modified
on B.

There is a problem, though: in VI A, the two loops cannot be
exited under the action of an "armed" button (VI won't
compile). One must use a simpler button type.

One things to be noted is that *this architecture works even
with multithreading disabled in LV!!!*.

Why this works at al is beyond me, but I would appreciate
explanations however.

For now I can go back to programming my stuff the way I like
(well, the way the client said it should be programmed 8-)

Many thanks to the two persons that tried to help me.

[Greg_McKaskle2]

> VI A the caller should have two While loops, with a "WAit"
> function of say 100ms; one loop is in charge of continuously
> displaying global variable V on the indicator, the other of
> calling VI B.
>
> VI B itself consists of a while loop where a command feeds
> and modifies global variable V. B is modal and centered, so
> it won't hide the indicator on A.
>
> This indicator is correctly updated on A when V is modified
> on B.
>
> There is a problem, though: in VI A, the two loops cannot be
> exited under the action of an "armed" button (VI won't
> compile). One must use a simpler button type.
>
> One things to be noted is that *this architecture works even
> with multithreading disabled in LV!!!*.
>
> Why this work
s at al is beyond me, but I would appreciate
> explanations however.

Glad you have it working. This dual loop diagram was what I was trying
to describe, but of course it is hard to describe diagrams in text.

LV loops do multitasking through cooperation. Long before LV ran on
threaded OSes LV loops multitasked, by having their generated code call
the scheduler about 10 to 20 times per second if there are no waits in
the loop, otherwise according to the calls to wait. With threads, the
underlying execution engine gets more complicated, but the diagram
executes much the same except it can take advantage of multi-CPU
computers and OS priorities.

As for the button, you can't have local variables on latched Booleans.
Latching is just resetting, and you can do this yourself after you
determine that everyone has read it. LV doesn't know whether to reset
after one read, two, etc. So it makes you take control.

Greg McKaskle