Problem with array of queues (one producer controlling multiple consumers)

[MaciekP]

Hi!

I have a problem with my application, considering I've already spent one day trying to solve it the solution is probably really simple.

The application is basically a producer/consumer pattern with many consumers, each of whom has its own message queue. All queues are stored in an array. The way queues are handled is the same for every loop and I've double checked if the array indexes in each loop are are correct (elements from each queue can be dequeued in only one place). Dequeue timeouts have the same value (10ms) in every loop.

Now the interesting part - all but one loop work correctly. For example when I enqueue "Exit" in the "GUI Main" subVI all subVI's except "Meas Main" exit correctly.

Here's the code:

Producer loop:

The consumer that's making problems:

Any ideas?

[KateB]

Can you post simplified version of your code that can replicate the problem?

[Norbert_B]

Well, several possible reasons:

1. Another consumer is already configured for the index "Meas.", so you have two separate dequeuer.

2. The error you send in the queue element reports an error (dequeue wont execute).

3. You kill the queue before the consumer can dequeue as you dont handle errors from the dequeue function, the consumer is stuck

4. Does this specific consumer work at all? So is it really connected to the "Exit" case solely or is it a general mistake?

5. Are you sure that dequeuing is the problem at all? Maybe you miss to terminate the consumer loop in the Exit case (passing F to loop terminal).

Norbert

[MaciekP]

It would take me some time to create a simplified yet working version, I'll do it if I don't solve the problem till the end of the day.

Thanks for suggestions Norbert but sadly it's something else...

If I remove this part (which is handling the GUI) it suddenly starts to work

Thanks for replying so quickly!

[Norbert_B]

That loop is definetly one of the most weird loops i've ever seen in LV.....

My first impression:

Hey, the event structure and the while loop block each other.

Whilst this is not necessary the case (due to the timeouts which you configured), the usage of the event structure followed by another case structure is close to a NO-GO. Please rework that part as such that the case structure is incorporated appropriatly into each event case.

My guess right now is that this display event structure also tries to capture the Exit Button event. But as, obviously, another event structure already executed this event, the event structure does not see this event leading to a lock....

Please check if the big loop keeps running when the exit should be executed. If this is the case, you have a race condition on the shutdown.

Norbert

[Yamaeda]

Have you got enough queues? If not, the measurement loop will work with empty information. What happens in the State? If it gets a Exit, will it pass it out or does something happen in there? If the other loops are constructed in a similar way you might get a Stop command before the main Exit.

What do the Breakpoints suggest? Do you get into this structure at all?

/Y

[MaciekP]

True, doesn't look good...

Works after setting the timeout value to default. I'll rewrite it from scratch though, thanks for help!

[mikeporter]

An axiom that I live by is, "If doing something in LV is a pain, you're doing it wrong.", and you code is a classic example.

The reason that you are using an array of queues is that (as you no doubt found out) only one consumer can get any given item in a queue. To work around this "problem" you decided to create an array of queues and all the complexity that "solution" entails.

The obvious answer, however, should be to not use queues in the first place - they don't do what you need done. What you need is some sort of construct or communications channel that all consumers will see every time - which it just so happens is exactly what user-defined events do.

Replace the queue with a UDE (which are also queued) and much of the complexity and confusion will go away. If you would like some details, I can explain the concept further.

Mike...