Semaphores and queue together. Is it necessary?

[dan07]

Ravens

The code is not working as I expected. While running in the Highlight Mode I saw that the State Machine starts working while the For Loop is still running (I put 6 states in the array just to make the For Loop runs longer).

Where is my mistake?

Thanks

Dan07

[battler.]

I have used Notifiers for this, not semaphores.  An advantage is you can also pass data with semaphores.

[nathand]

One problem is that you fork the semaphore reference wire just before locking the semaphore, so the lock may not be set until after you start enqueueing elements (which will then allow the other loop to start dequeueing them).  You need to wire the reference out through the for loop to force the lock to occur first.

[Daklu]

---

dan07 wrote:

The evaluation of the time of day was just an example. What really happens inside the State 1 is a code that will open a File Dialog and allow the user load a ascii file. Nevertheless, if the user closes the File Dialog the "open file operation" is cancelled and is no longer necessary to run State 2. This is the real situation. I would like to use the producer loop just to enqueue elements and not do any kind of evaluation or operations inside it.

---

I'm going to go out on a limb and diverge from conventional wisdom and the collective advice given so far...

The fundamental problem as I see it is that your states have not been properly defined.  The queued state machine pattern can be useful for quick and dirty prototypes; however, in common practice it usually devolves into a "function machine" rather than a state machine.  What's a "function machine?"  It's a state machine that uses states where where it should be using sub vis.  Typical characteristics of a function machine are lots of states (say, more than 10) and queue manipulation logic in the consumer loop.  For many reasons function machines are hard to maintain and can contain nasty bugs.  I suggest avoiding the QSM pattern altogether.

If you must use the QSM, here are a couple rules of thumb I like to follow:

-Other than dequeuing states, don't let the consumer loop manipulate the queue.  Definitely do not add states to the queue in the consumer loop.

-Only create states for the process "entry points."  Entry points are those initial states the producer must invoke.  In your example state 1 is an entry point.  State 2 is not.

To address your specific problem, there are a couple ways to solve it without introducing semiphores at all.

Option 1

Remove state 1 and move the load dialog to the producer loop.  If the user cancels out of the dialog box simply do not add a state to the queue.  If the user does select a file, pass the filename to the consumer loop as message data.

Option 2 

Convert state 1 and state 2 into sub vis and condense them into a single state.  Put the state 2 sub vi in a case statement so it is conditional on the user selecting a file from the dialog box.

(LAVA discussions on QSM can be found here and here.)

Message Edited by Daklu on 04-18-2010 10:38 AM

[RavensFan]

---

nathand wrote:
One problem is that you fork the semaphore reference wire just before locking the semaphore, so the lock may not be set until after you start enqueueing elements (which will then allow the other loop to start dequeueing them).  You need to wire the reference out through the for loop to force the lock to occur first.

---

Also, in the consumer loop, the lock queue is not preventing state 1 from starting.

There is no reason you should need to use a semaphore.  But if you are going to use them, I suggest you look in the example finder so you can learn how to use them properly.

[battler.]

Daklu,

Interesting insight.  If you don't recommend QSM structure, what structure do you recommend and why?

Cheers,

Battler.