Why can't I add a state to the Queue from UI loop?

[HTMike]

Hello:
I have been building onto a framework that has a flaw. I have a User Interface loop to catch all UI events using the event structure, and main state machine that shares the state queue.
I find that I cannot DeQueue from the Queue "bus" if the state was put on by the UI loop.
It was recommended to me to add a Dequeue inside the UI loop for every EnQueue but I find that in the real application I miss states sometimes.
Attached I have a test app that shows you a skeleton of my app and uses the Get Queue Status VI. There is a readme file in the zip.
Can someone tell me why DeQueue is not taking states off the Queue when added in UI loop?
Thanks

[HTMike]

Labview has some issue to work out with DeQueue. I inserted the vi GetQueueStatus in front of the DeQueue, checked to see if the number of Queue elements was >1, if so I would execute a seperate DeQueue to get rid of the element. This solved the problem of the Queue growing OUT OF FREAKIN' control but I loose the whole purpose of a Queue. I increased the main wait loop to 2.5 sec. and watched how the Queue built up and then it hit me -- LabView DOES DeQueue elements from another loop (on the same Queue bus) - IT DOES NOT SHRINK THE SIZE OF THE ELEMENT ARRAY AFTER IT GETS THE ELEMENT FROM ANOTHER SECTION OF THE QUEUE "bus". This seems like a bug to me.

[Joey Oravec]

Hi,

Maybe if you can post the diagram in question we could better provide an
answer. I use queues all the time and they seem to work. I've got a guess at
what you're seeing, and a suggestion to change things.

My guess: Remember that if you have code in parallel, it will generally run
simultaneously. Queue (push) and Dequeue (pop) operate as you would expect,
but YOU must enforce the ordering like in normal thread programming.

If you're adding elements more quickly than they can be processed, of course
the queue would grow without bound. However it sounds like there is some
parallel programming problem. Posting more details would probably help.

My suggestion: One addition problem is your GetQueueStatus and Dequeue.
Those two are not guaranteed to occur atomically ("at once"). You might have
a third thread somewhere which also dequeues elements from the same queue.
Imagine the situation where loop2 runs getqueuestatus (it's =1), loop3 gets
some processor time and pops that element, then loop2 takes back the
processor and tries to pop but the element is already gone.

So if you're operating on a queue, you don't need to do a GetQueueStatus
before DeQueue. Simply run dequeue with timeout set to -1 (wait forever).
This way dequeue waits patiently until there is something in the queue to
pop.

-joey

"HTMike" wrote in message
news:50650000000500000003E50000-1042324653000@exchange.ni.com...
> Labview has some issue to work out with DeQueue. I inserted the vi
> GetQueueStatus in front of the DeQueue, checked to see if the number
> of Queue elements was >1, if so I would execute a seperate DeQueue to
> get rid of the element. This solved the problem of the Queue growing
> OUT OF FREAKIN' control but I loose the whole purpose of a Queue. I
> increased the main wait loop to 2.5 sec. and watched how the Queue
> built up and then it hit me -- LabView DOES DeQueue elements from
> another loop (on the same Queue bus) - IT DOES NOT SHRINK THE SIZE OF
> THE ELEMENT ARRAY AFTER IT GETS THE ELEMENT FROM ANOTHER SECTION OF
> THE QUEUE "bus". This seems like a bug to me.

[HTMike]

Joey:
Thanks for your comments. I originally posted a sample of the problem. Plese find it here. I will study your suggestions and get back to you.
Mike

[Greg_McKaskle2]

> My guess: Remember that if you have code in parallel, it will generally run
> simultaneously. Queue (push) and Dequeue (pop) operate as you would expect,
> but YOU must enforce the ordering like in normal thread programming.
>

This is all good advice. I'd just like to add that one has to carefully
think through the use of a queue and other synchronization primitives,
especially when used in multiple locations. In most situations, you
will want to limit the queue usage to a single writing location
and a single reading location. The reading and writing locations can be
increased provided they process the element in the same way. Do not
jump to the conclusion that the the various queue readers each receive a
copy of the element adde
d to the queue.

Greg McKaskle