Producer Consumer with Queues

[SercoSteveB]

What is the value of Numeric Value Out following execution of the VI?

a) -1

b) 0

c) 3

d) 4

[#2]

a)

[LordNobady]

A. It is the only value that the VI will stop executing with.

[crossrulz]

A

Thanks for showing a proper way of stopping a Producer/Consumer.  The NI examples stop the consumer by closing the queue and therefore causing an error.  The problem with that is that you may not get to process all of the data before the queue is closed.  By sending a stop command of some kind in the queue, the consumer can be sure to process all of the data.

[MrStevenUND]

A.  I'm looking for some gotcha, but there is only one way to cleanly stop execution (ie no error, etc)

[crossrulz]

MrStevenUND wrote:

                       

I'm looking for some gotcha, but there is only one way to cleanly stop execution (ie no error, etc)

                   

If there was an error in or before the consumer loop, we wouldn't be able to stop.  So for that reason, you should find some way to handle your errors.

[clendon.gibson@canrig.com]

A as everyone has already noted.

[sportscliche]

Hmm, this is not what I remember learning in Core 2.  Are you saying that when the producer releases the queue and sends an error to the consumer, it will immediately stop and all data that is waiting at the consumer will be lost? 

[#9]

The LabVIEW Core 2 exercises typically destroy the queue and use the generated error to force the consumer loop to exit. This does cause any queued data to be lost sportscliche. One of the 1st exercises (Queues v Variables) in the current LV Core 2 implements code to ensure the consumer has read all the data from the queue before destroying it. There are other exercises where we place a 'shutdown' message into the queue at the opposite end. In turn this will also cause data to be lost, unless we implement extra code.

The above example will not exit until the queue is empty, because the value -1 is the last piece of data placed in the queue. It is effective, but we could kick off a debate on code readability.

[crossrulz]

sportscliche wrote:

                       

Are you saying that when the producer releases the queue and sends an error to the consumer, it will immediately stop and all data that is waiting at the consumer will be lost? 

                   

Watch your terminology here.  If a producer releases a queue, it does not send an error to the consumer.  The consumer will throw an error due to its reference being destroyed.  And yes, whatever data is in the queue when it is released will be lost.

As far as readability, just make sure you document how you are stopping the consumer and it will become apparent fairly quickly with almost all of the Producer/Consumer setups I have seen.

[sportscliche]

OK thanks.  I just tested this and confirmed that queued data can indeed get destroyed if the error propagates to the consumer before the queue is processed.

[crossrulz]

sportscliche wrote:

                       

OK thanks.  I just tested this and confirmed that queued data can indeed get destroyed if the error propagates to the consumer before the queue is processed.

                   

I'm not sure you understand what is happening based on how you are saying this.  When you destroy the queue, its reference becomes invalid.  When the consumer tries to read from an invalid reference (since producer and consumer use the same reference), the Dequeue generates an error (error code 1, I think from the top of my head).

It is exactly the same thing if you tried to read from a file using the file reference that has already been closed.

[SercoSteveB]

Answer: A.  Nice one DavidCorney, LordNobady, crossrulz, MrStevenUND & clendon.gibson@canrig.com.

Great discussion.  I would advocate always having error handling across all loops (unless you are attempting to write a CLAD question where simplification is important) of an application and always have mechanisms for stopping an application (not just relying on propogation of errors).