The Mystery Code Thread

[altenbach]

Once in a while I run across some code that makes my head spin and I am trying to figure out one of the following questions:

• "What was the programmer thinking when wiring this??!"
• "Is there any possible reason that this code makes sense and I am just not gettting it??"

This thread should serve as a place to investigate such Code fragments. Maybe the collective brains of this forum can find a clear explanation. 🙂

.

Let's have a look at a small subVI program with a name containing "time delay" posted here.

.

.

Look at the diagram picture. The only reason that I can think of is that the original problem description was: "Create a VI that will never stop if it is run in execution highlighting mode". 😮

.

The VI will only work correctly if the bulk of of the loop content is guaranteed to execute within the same ms tick. (Else it will keep trying, possibly forever.) Fortunately it seems to work correctly as is, but why take the risk??

.

Is there are conceivable justification for all these wires? The tick count? The addition? The comparison? The while loop? Am I missing something obvious?

. 

(The reason for the "invert" is clear. Back in the old days, loops only had "continue if true" mode for the termination condition.)

[Ben]

Could that be a "over-load" detector?

I'm thinking that code running in parallel with other code will keep running until the app becomes CPU bound and there aren't enough slices left over for toher threads so that one can drop out.

Just guessing.

Ben

[altenbach]

Interesting guess. I highly doubt that the loop diagram will get sliced by a thread switch here, but I would not know... Let's do some testing!

Even on a lightly loaded machine, there is a small chance that the wait is twice as long, simply because we might (by chance!) be very close to a tick count turnover. For example in the following code we can see that in a finite fraction of calls, the loop spins twice, thus doubling the delay. There is an even smaller chance that it spins three times, tripling the delay! The code is not deterministic!

Now lets add two greedy while loops to gobble up all spare CPU (I am on a dual core system), and yes, the chance for a double-delay is 5x higher.... maybe you are on to something here.

Still, would it really make a difference? Even here the chance for a double delay is less than one percent. Lots of code at the cost of determinism and no obvious gain. 😄

In any case, code such as this requires a diagram comment! 😉

[JÞB]

The butler coded it?  possibly forever?

OMG (at the risk of offending certain participants) The code is a "Who done it!"

[JÞB]

---

Will the deceased body be found?   Yup- under the uncommon circumstances described-Yet,  Probably the "corpus delectii" will not be in evidence.......

^^^ LowerLoop 1 we "hide the corpse"  ^^^ Lower Loop 2 we "destroy the time stage of the crime"

CSI writers- The perfect crime ......

In any case, code such as this requires a diagram comment! ; Or a corpse!

---

---

[Ben]

Hi Christian,

You alluded to but have not concidered a imporatant fact, this appears to be old code from prior to the option to "stop" if true for the termination terminal. Try runing the test with;

ESys.StdNParallel=0

(after restarting of course) in the LV ini file to force LV to run single threaded like in LV 5.0.

Ben

[altenbach]

Ah yes!

I think I can do the same (without impacting my entire development system!) by settting it to run in the UI thread, here's what I found:

(1) Without the two extra while loops, and setting a 1ms wait, I get the following histogram of actual delays.

1ms: 26268

2ms: 3205

3ms: 239

4ms: 8

5ms: 0

...

inf: 0

We get a >10% chance of extra delays!

(2) With the two extra while loops, the VI never finishes (!!) and gets stuck in the inner while loop forever!

1ms: never

2ms: never

3ms: never

...

inf: 100% !!!

This also means that if the application is not carefully designed and for example contains greedy polling loops, there is a good chance that the program locks up and can never finish!

Did it ever make sense to "over-engineer" a time delay in such a way? Maybe!

Has anyone else ever seen this construct? Could it be it was a widespread and accepted method to throttle sections of code in ancient times? I really don't know.

If this in fact was the functional intent, the VI name should have been more clear, e.g. "low priority time delay" or similar. Of course the complete lack of documentation is not helping either. No description, no diagram comments, etc.

[AnalogKid2DigitalMan]

I know where that code comes from and what its intent was. I came across it many years ago but never ended up using it for a potential project.

-AK2DM

[LV_Pro]

"I know where that code comes from and what its intent was."  Pretty cryptic!

[Ben]

So we have a witnes be he ain't takin. He did give as clue "THe question drive us" so....

Twenty questions it is!

Q1) Is it used to detect the load on the CPU?

Ben