Event Structure as State Machine

[Val Brown]

I do understand what you're saying but, if you're looking for objective measure to validate your BIAS, and the objective data does NOT support your BIAS, then is it possible that this is just a BIAS?

Now don't get me wrong. I'm not saying that there are reasons to prefer the other approaches but to claim that there are objective measure to validate your preference -- when there apparently aren't -- puts you in a far, far weaker position.

What are the real reasons you oppose that approach? You may have already posted your thinking and I missed it but, if you're looking for objective validation, I think you may be out of luck.

[PeterB]

I do understand what you're saying but, if you're looking for objective measure to validate your BIAS, and the objective data does NOT support your BIAS, then is it possible that this is just a BIAS?

Possibly, but I think you will find it is also the BIAS of many other seasoned LV programmers too. Is it possible so many are all objectively wrong ?? Have we been told lies by our learned forefathers about staying out of the UI thread unless necessary ?

I dare a seasoned LV programmer to step up and support the notion of an ESSM+VSB !! (to the point they would use that as the default template in their next major project.). I would be very surprised if we would get more than 5% of experienced LV programmers seriously supporting it. I'm happy to be proven wrong, but if something has such an opposition to it, I don't want to let it become a template at my work.

mross wrote "That is crazy talk what he did with the LED indicators. "

What are the real reasons you oppose that approach? You may have already posted your thinking and I missed it a BIAS?

here is a list of CONs I came up with. A few are objectively measureable.

rgds

[Tim_S]

Possibly, but I think you will find it is also the BIAS of many other seasoned LV programmers too. Is it possible so many are all objectively wrong ?? Have we been told lies by our learned forefathers about staying out of the UI thread unless necessary ?

I'm reminded, in medieval times, that everyone knew tomatoes are poisonous to humans. (Actually it was the acid in the tomato causing the lead in the plates to leach into the food. This appears to be an English and American belief from what I've looked up.)

I don't think I've seen this structure and it doesn't sound like something I'd use. Do you have an example?

[PeterB]

Tim, I'll post it tomorrow from work. I'm pretty sure the ESSM+VSB will never be likened to the humble, red, juicy and appealing tomato. More likethe green kind which is toxic in large amounts.

rgds

[PeterB]

Tim, I'll post it tomorrow from work. I'm pretty sure the ESSM+VSB will never be likened to the humble, red, juicy and appealing tomato. More like the green kind which is toxic in large amounts.

Here it is Tim. Have a play around with changing the control labelled "State Change Delay [ms]" (which pops up when you run it) and see how it can't keep up for lower delay values. Globals are used generously much to my distaste, but it was primarily what was given to me and I then had to distil it in a short amount of time.

Just a reminder to you and others. My goal is to throw situations at this architecture which prove it is poor from an objective standpoint. I want to show how loading up the UI thread with events will prove detrimental under any conceivable situation. (e.g. FP refreshes being less responsive, especially when that FP is moved around)

I revise my last claims in that it starts becoming less responsive for total rates of 200Hz (rather than about 1.5kHz), but not noticeably so, only because the metric I've included (time drift [ms]) indicates this.

The total event firing rate of the 20 parallel sub vis (which I neither calculated nor displayed programatically) is simply = (20000/State Change Delay [ms]).

ESSM+VSB Folder.zip

regards

[Tim_S]

Here it is Tim. Have a play around with changing the control labelled "State Change Delay [ms]" (which pops up when you run it) and see how it can't keep up for lower delay values. Globals are used generously much to my distaste, but it was primarily what was given to me and I then had to distil it in a short amount of time.

My first reaction to your example is to reach for the crosses and holy water. I have old code with some similar behavior which was difficult to follow and debug. I abandoned that line of coding due to the difficulty in debug and maintenance. I didn't have performance issues with what I was doing (a configuration editor), however the debug and maintenance was unpleasant enough that I have a definite bias against such a structure.

Tim

[ned]

Just a reminder to you and others. My goal is to throw situations at this architecture which prove it is poor from an objective standpoint. I want to show how loading up the UI thread with events will prove detrimental under any conceivable situation. (e.g. FP refreshes being less responsive, especially when that FP is moved around)

I think a much more successful approach will be to find reasons why this is a difficult architecture to develop, maintain and extend. On fast modern hardware it's often hard to prove that inefficient code will actually cause problems. For me, the inability to manipulate the event queue is reason enough to prefer a standard queue. There's no way to separate events generated by the user from events generated programmatically, so if you need to sequence through several states programmatically and the user generates an event somewhere in the middle of that, you may end up interrupting your sequence unexpectedly. This could be solved with a second event loop that only handles the Value (Signaling) events, but that's ugly, and anyway, if you're adding another loop, why not just use a queue?

[Daklu]

I think the reason you're not seeing a hit to UI performance is that you're not loading up the event queue. You're throwing a lot of events at it, but the queue is staying pretty clean. I suspect you'll see performance issues if you have one event case fire off a bunch of value signalling events (say, 100) before exiting. The performance issues won't be in moving the window around--that's managed by the os. It will be in the responsiveness of other fp controls. (Changing tabs, pressing the exit button, etc.) Alternatively you could increase the wait time in states 1-3.

The scenarios I suggested are contrived to expose the weakness of serialized UI events, but once understood can be avoided. The bigger problem with this architecture (which the QSM also suffers from) is the danger of injecting an unexpected "state" in a chain of states. In the attached project, I've increased the number of states to 5 and lengthened the state wait time to 500 ms to make the issue easier to see. Start it up, then hit the Restart button and watch what happens. Interesting, huh? Now try activating the other tabs or exiting. How "easy" is it going to be for a LV newbie to avoid creating this kind of situation or understand what is going on once he has run into it?

Objectively it looks like your argument is a bit thin. Unfortunately not everything of value can easily be measured. There are several comments from people who have used the pattern and reported having difficulty understanding and debugging the code. It doesn't matter how easy the code is to write; if you can't read it then it's value is limited.

At least with the QSM you can work around the problem in this example by clearing the queue when the Restart button is pushed. The issue as a whole still exists though, and while there are solutions to specific scenarios I believe this in an inherent flaw in the strategy of queueing up sequential process steps that cannot easily be resolved.

ESSM+VSB Modified.zip

[jdunham]

Peter, I've used LabVIEW for a long time and played with various architectures. I'm like Daklu in that I don't think state machines are very good at all, but I do use message handler engines for a lot of code (apologies to Dave if I'm misrepresenting him). Anyway I agree with you that I would much rather send my messages over a queue than the event structure, since if you get into a bind, you can always write code to inspect the queue or change its behavior, whereas you don't have any ability to mess with event structure events until they come back out the other side.

If you looking for a groundswell of support, why don't you set up a poll on LAVA? A lot of people like me probably have opinions but don't have time to compose a detailed thesis, but you can crowdsource us to get what you need.

Edited July 13, 2011 by jdunham

[Val Brown]

Every thing is a problem in some context and everything is also a resource in another. The "difficulty in maintaining" such code can be an advantage when you are trying to make it as difficult as possible for someone to reverse engineer your code -- and that has always been a critical consideration for me. Now, I'm saying that support or oppose the use of the specific pattern being discussed. But I am emphasizing that it may be accurate to say that it is "objectively" problematic.

[Daryl]

QUOTE(PeterB @ Nov 9 2007, 10:00 PM)

......

They lead to yet another form of race conditions. I tend to use controls and indicators as a "window" into the data I store in Action Engines.

.......

Ben

What is an "Action Engine" ?

[Val Brown]

"Action Engine" is another term for a Functional Global Variable or FGV.

[Tim_S]

What is an "Action Engine" ?

LabVIEW Wiki

[Daryl]

"Action Engine" is another term for a Functional Global Variable or FGV.

Thanks.

[Daklu]

apologies to Dave if I'm misrepresenting him

Nope, I don't think you are. I will add two points of clarification:

1. I think state machines are good--it's queued state machines (or any architecture that uses queue-like constructs to control sequential processes) that I don't like.

2. The difference between a QSM and a message handler is not well defined. IMO, it's all in how it's used, not what it looks like.

[PeterB]

Dave, thanks for taking the time to look at this and code up something for me to try out.

I think the reason you're not seeing a hit to UI performance is that you're not loading up the event queue. You're throwing a lot of events at it, but the queue is staying pretty clean. I suspect you'll see performance issues if you have one event case fire off a bunch of value signalling events (say, 100) before exiting.

I just tried programatically firing off 1000 UI events in a for loop, but it didn't upset things at all. Even if it did, such a scenario would be a highly unusual use case.

The performance issues won't be in moving the window around--that's managed by the os. It will be in the responsiveness of other fp controls. (Changing tabs, pressing the exit button, etc.) Alternatively you could increase the wait time in states 1-3.

When I mean "moving the window around having an effect ", I am referring to the graphs and LEDs not updating smoothly. I have seen them jitter and stall as I move around the Main FP. This is not just a cosmetic problem, it is also affecting the time it takes to complete each state.

The bigger problem with this architecture (which the QSM also suffers from) is the danger of injecting an unexpected "state" in a chain of states. In the attached project, I've increased the number of states to 5 and lengthened the state wait time to 500 ms to make the issue easier to see. Start it up, then hit the Restart button and watch what happens. Interesting, huh? Now try activating the other tabs or exiting. How "easy" is it going to be for a LV newbie to avoid creating this kind of situation or understand what is going on once he has run into it?

Your changes were successful in demonstrating how injecting an arbitrary state affects the order of execution of the other states which is also a problem with QSMs but can be salvaged by flushing a QSM's queue. That is one more CON for this architecture, thanks for pointing that out. (I had only considered the example of wanting to enqueue an error state to the very front then being unable to flush the remaining enqueued states, but you bring up a generic problem - thanks)

The other problem you tried to point out unfortunately (for my case) is not really a problem. It is true that the FP is unresponsive to user input after Restart is pressed - but this is caused by the Graph Update state (and possibly the other new states you added) having the "Lock front panel (defer processing of user actions) until this event case completes" checked. That is the default setting and needs to be unchecked for this architecture for it to have at least any hope of being useful.

Objectively it looks like your argument is a bit thin. Unfortunately not everything of value can easily be measured. There are several comments from people who have used the pattern and reported having difficulty understanding and debugging the code. It doesn't matter how easy the code is to write; if you can't read it then it's value is limited.

I think you make a great point here. I was surprised that sending so many UI events didn't hammer the UI thread. It only hammers it if one simultaneously displays all the LEDs for each of the states being entered into. In fact a prior version I achieved this by firing off 8 states in the Main top level vi from parallel vi's , and only when those 8 state LEDs were visible did it saturate one of my 4 cores on the CPU.

[PeterB]

Thanks everyone else for your replies. Before I address each one individually if others have additional reasons they would avoid using this architecture please feel free to chime in. With the supposed performance issue not being demonstratable under typical worst case scenarios I have kind of lost my one big CON to throw against it. so it might just have to be a lot of smaller CONs now which will support my/our bias against the architecture.

Tim, it might well come down to declaring this a demonic design and casting it out, but until that point I want to gather as much objective and subjective evidence as possible to counter it so I can be fair to the person pushing really hard to have it accepted.

Ned, good point about being unable to manipulate the event queue. that seems to be a common thread/CON with this architecture as I pointed out to Dave.

Jason, thanks for your vote for queues rather than event structures to send messages. I think I might set up a LAVA poll. Your replies to date will help me form unbiased questions.

Val, being harder to follow the code is definitely a CON as it needs to be easy for beginners to understand and anybody to maintain. I gather that the main reason it is hard to follow if the use of Global Variables which aren't strictly necessary to use for this architecture.

regards

Edited July 14, 2011 by PeterB

[Val Brown]

With the supposed performance issue not being demonstratable under typical worst case scenarios I have kind of lost my one big CON to throw against it. so it might just have to be a lot of smaller CONs now which will support my/our bias against the architecture.

Yes this was essentially the point I was making in my initial reply. There may be many reasons to not prefer -- or even use -- this architecture but claiming that there are objective measures supporting that -- when there aren't -- is a bit of problem.

Val, being harder to follow the code is definitely a CON as it needs to be easy for beginners to understand and anybody to maintain. I gather that the main reason it is hard to follow if the use of Global Variables which aren't strictly necessary to use for this architecture.

Not in my case in fact, it specifically is essentially a requirement that no "beginner" can come in and understand my proprietary code. It is one of the few real safeguards I have available to me. And the obfuscation has nothing to do with Global Variables, which I simply do NOT use (even though there are use cases in which they are serviceable). Global assertions (eg "X is NEVER a good idea") are just another application of Global Variables and generally carry with them all of the attendant sorts of issues such references bring...

[PeterB]

Yes this was essentially the point I was making in my initial reply. There may be many reasons to not prefer -- or even use -- this architecture but claiming that there are objective measures supporting that -- when there aren't -- is a bit of problem.

Not in my case in fact, it specifically is essentially a requirement that no "beginner" can come in and understand my proprietary code. It is one of the few real safeguards I have available to me. And the obfuscation has nothing to do with Global Variables, which I simply do NOT use (even though there are use cases in which they are serviceable). Global assertions (eg "X is NEVER a good idea") are just another application of Global Variables and generally carry with them all of the attendant sorts of issues such references bring...

OK thanks for clarifying Val.

Also, just to be clear, up until now I've not claimed, nor do I want to claim that the ESSM+VSB should NEVER be used, just that it is not a design that should be put forth as a contender for a template upon which many small and large programs will be written at my company. We are only settling on one template for now. In 6 months time we might add another one to the mix. I'd like to think that by the time we get to template number 8,9 or 10 that the ESSM+VSB stands a chance because of the few times it would be useful.

rgds

[Daklu]

Brief diversion...

...it specifically is essentially a requirement that no "beginner" can come in and understand my proprietary code.

Do you mind if I ask what environment you work in that requires you to obfuscate your code?

[Val Brown]

Brief diversion...

Do you mind if I ask what environment you work in that requires you to obfuscate your code?

Yes, you can ask, of course.

I'm a single developer, having founded my own company with my partner -- who is my wife -- and we have developed and distribute a completely unique application that has required not only specialized knowledge in order to be developed, but specialized knowledge across a number of domains. Aside from the You can check out our website for further info and i'm happy to discuss it further here as well: www.zengar.com.

Competitors have already tried to claim that their product does what our does -- and failed -- but several have mounted concerted effrorts to reverse engineer our code -- and failed.

I'm not a developer for hire and I doubt that I ever will do that. If I did -- esp if I headed up a large multi-person team -- then there would be different concerns that would drive this bus. But in our situation, security of the code is critically important. Obfuscation and such are fundamental components of insuring that our code, ideas and unique application remain ours alone.

[Daklu]

I'm not a developer for hire and I doubt that I ever will do that.

Ahh... I understand your concern and I can see how obfuscation would be a critical part of maintaining your ip. I have always assumed compiling into an executable provided a reasonable amount of protection from reverse engineering, though I do now vaugely recall prior discussions about how easy it was to dig into an exe to rev eng source code.

BTW, I found this on your site:

Win7-64, IE9.0.1.

[Tim_S]

it might well come down to declaring this a demonic design and casting it out, but until that point I want to gather as much objective and subjective evidence as possible to counter it so I can be fair to the person pushing really hard to have it accepted.

Unfortunately, the only thing I can contribute is that it was very difficult to debug similar design elements to the core of this style of state machine.

Tim

[Yair]

...though I do now vaugely recall prior discussions about how easy it was to dig into an exe to rev eng source code.

Not that easy. You can theoretically* access VIs, but since they don't have their block diagram, they are only going to be of limited help.

* I say theoretically because I believe this was made harder in 2010, although I'm assuming it's still far from impossible.