Semaphores and queue together. Is it necessary?

[F._Schubert]

Queues 'break' dataflow.

This is necessary to communicate between two (or more) parallel loops. You will always need something that 'breaks' dataflow in these situations, such as global variables (bad), LV2globals/Action Engines, ... Queues are a very elegant solution to manage this.

Felix 

[dan07]

F. Schubert

You are right about Queue "breaking" the dataflow. I've been reading some posts about queue and this function is really very nice. When you have a very small VI with no SUBvis, is "possible" to use local variables in a safe way, because you can see everything in one single block diagram. If you have a main VI with two or three SUBvis, you can use Globals... but I prefer to don't use them in any circunstance. I prefer to wire everything and keep away from race conditions. I never saw a situation that globals and locals were the only option. There is always another way to do the same thing.

Dan07

[Ben]

---

Daklu wrote:

---

Lucither wrote:

Has given me something to think about as i have to admit that sometimes i fall into the trap of writing 'Function machines' as you have called it.

---

I think everyone does; it's part of the learning process.  Below is a diagram of a QSM I had a hand in creating just last year.  (Of course, I didn't create the diagram until it became too hard to follow the execution in code.)  This is just the diagram for the Start Test button!  This project is what prompted me to examine the QSM and look for better ways to implement it.

---

So THAT is the reason you were asking about diagraming the QSM.

Thank you very much for the nice posts you have contributed to the this thread Daklu!

I going to tag this one so I can find when i need it.

Ben

[dan07]

Does anybody had problems viewing the QSM diagram? I can't read anything on it.

Thanks

Dan07

[battler.]

Yeah, can't read it.  Would it really help?

[Daklu]

---

dan07 wrote:

Does anybody had problems viewing the QSM diagram? I can't read anything on it.

---

I purposely reduced the size to a point where the states themselves are unreadable to protect proprietary information.  My intent is to illustrate the complexity that can easily occur as you add functionality to a QSM.  Except for the red and yellow circles, each one is a separate state in this state function machine.  That's a lot of cases to trace through trying to make sure the branching logic is correct for all user scenarios.

While developing this state diagram I discovered a significant bug in our state function machine.  Under certain situations one of the states would queue up additional states expecting that they would be executed next.  Sometimes there would already be states in the queue that would be executed first, and which would in turn add more states to the queue.  This resulted in parallel execution paths being interleaved on the queue that would have caused completely unpredictable behavior.  Note this bug wasn't discovered through testing--had we seen it at runtime it would have been difficult to replicate and identify--but by code analysis.  Code analysis is much harder to do in a QSM than in a block diagram that uses standard flow control prims.

The PreTestValidation and ExecuteTestCases blocks I added after figuring out the state transitions.  If I ever have to do significant coding on that part of the project I'll condense all the states in each of those blocks into high-level sub vis and use standard flow control rather than relying on a queue.

[Daklu]

---

Ben wrote:

So THAT is the reason you were asking about diagraming the QSM.

---

Yep.  Ugly, isn't it?

---

Ben wrote:

I going to tag this one so I can find when i need it.

---

Yeah, it's always helpful to refer back to how NOT to do things.  😉

[Ben]

---

@Daklu wrote:

---

Ben wrote:

So THAT is the reason you were asking about diagraming the QSM.

---

Yep.  Ugly, isn't it?

---

@Ben wrote:

I going to tag this one so I can find when i need it.

---

Yeah, it's always helpful to refer back to how NOT to do things.  😉

---

I am bumping this thread because of a recent discusion in my bull-pen. One of the CS types I worked made the arguement that the QSM is actually LV's version of a Goto Statement, which Dijkstra concidered bad and I I rememeber what I was told correctly introduces chaos (I amy be wrong on that point, and that was just my wife saying they introduce chaos).

in the large scale apps I have seen based on the QSM, i was repeatedly challenged with trying to figure out what happened before the error happened and I needed a trail of bread crumbs to figure it out.

Anyone with more CS background than myself care to comment?

Looking to learn something,

Ben

[Todd_Lesher]

-- deleted --

[Daklu]

---

Ben wrote:

One of the CS types I worked made the arguement that the QSM is actually LV's version of a Goto Statement...

Anyone with more CS background than myself care to comment?

---

(Whether I have "more CS background" than you is questionable, but I'll comment anyway.  )

Is the QSM Labview's version of the Goto statement?  I think the answer depends on what properties of the QSM and Goto are being compared. 

Ways the QSM and Goto are similar

-easy to implement.

-hard to implement correctly.

-easy to chage.

-hard to change correctly.

-overused by developers.  (Especially relatively inexperienced developers.)

-useful in a limited set of circumstances.

-allow nearly unlimited branching.

-obscure the program's execution flow.

-encourage "code and fix" programming.

-hide subtle logic errors.

Ways the QSM and Goto are not similar

-Goto is a statement; QSM is a construct.  They serve slightly different roles.

-Goto is used inside functions.  QSM is a container for functions.

-Goto is widely regarded as a "bad idea."  QSM is not.  (Yet.)

-Goto (in most common languages) is more restrictive than the QSM.  It was not possible to Goto a location defined by a variable.  You could only Goto a fixed location defined by a label or line number in source code.  The QSM allows you to change the destination of the next Goto jump at runtime.

In my mind they carry the same stigma, but I personally don't think of the QSM as LV's version of Goto.  The functional equivalent of the QSM in text languages is more like a switch statement wrapped in a loop, but with the switching variable stored in a queue and exposed non-locally.