Do LV Queues guarantee ordering?

[Valarauca]

When dealing with high speed queues <4ms between writes, and equally fast reads. I'm getting data that is out of allignment. Meaning if I insert

      Q <- Insert 1

      Q <- Insert 2

      Q <- Insert 3

      Q <- Insert 4

I'll sometimes get

      Q.flush() -> [ 1, 3,2,4 ]

Is this normal behavior?

[Norbert_B]

No it's not. Do you have multiple enqueuers?

If so, what makes you sure that 2 enqueues before 3?

Norbert

[billko]

If you are queuing from multiple places, there's no guarantee what will go in first.  That being said, though - if FIFO wasn't the case for each enqueue, none of our code involving queues would be reliable.  Enqueue opposite would have no meaning, either.

If you are queuing from only one place, I would check to make sure the data is actually arriving in order.  Maybe you have some kind of race issue that causes values to change before they get queued?

[Valarauca]

1) yes a 2 thread producer consumer loop.

1 thread writes, the second thread reads. That's the only 2 times this queue is called (other then its creation).

2) The example I provided was a conceptual example, not a literal example. What I'm actually dealing with is 600 index long, 84 index wide 2D 65float array pulled DAQmx.

2.5) No changing the size of the read doesn't affect this and changing the time between reads has little effect either.

[MarcDub]

Give us the simplest example of code you can make that shows that behavior. I suspect that something is missing in your story.

[Norbert_B]

Honestly, i understand little to nothing from your post....

So you have ONE producer which enqueues values and ONE consumer dequeueing values. Is that correct?

If so, the order of elements you dequeue is exactly the order in which you enqueued unless you are using "enqueue on opposite end".

That being said: What makes you confident that elements are in wrong order?

Norbert

[Valarauca]

My question is about the language specification not about this one instance in general. I know the G programming language will delay execution of a VI until all inputs are saturated. The real question I'm asking is if when rapidly enqueueing objects the G runtime environment will delay the insertion of an object until its VI is avaliable, and if this mechanism is not stricly order via call... Hence the ENQUEUE_VI itself cannot gaurentee that calls to it, will not necessarily be executed in the order that they're called from.

I've grabbed some screen shots from the application

Here is where the DATA leaves DAQmx and enters Queue.

That Sync VI is just a VI that ensure the time stamps (derived from To field of the wave form pulled from DAQmx, is always greater then the previous value)

So now we get to Dequeue

Only Novel Data.vi job is to remove data that has been seen before (I.E.: Repeating time stamps, which can occur very very rarely). This VI hasn't presented an issue in the slightest. But as I'm runing DAQmx over 4000/Samples per second I start getting data misorder (customer contract requires this).

Its contents

Here is the output of all this together. What's graph is my time stamps from mxDAQ this are the raw values, every value I get

The issue is lower values are arriving long after higher values. Meaning I'm traveling back in time, or something weird is happening. Lasty the data is only missordered in blocks of ~600 which is my DAQmx Read Size (and each 600 data points is 1 item inserted into the Queue, hence my questions).

[RavensFan · Accepted solution]

I don't understand what your last picture with the Excel sheet is supposed to show.  I see a bunch of numbers called relative time.  Sometimes they are longer, sometimes shorter.  But they are all positive, nothing looks like it is going back in time.

It is hard to debug from a series of pictures that are partial screenshots.  There is no way to tell what is relative to what, what structures are surrounding the elements.

I see one enqueue function and one dequeue function.  But the Enqueue is Enqueue at opposite end.  That means you are placing the element at the front of the line cutting ahead of anything that was placed in the queue earlier, but has not been processed yet.

I bet if you use the regular Enqueue function, your problem goes away.

[Valarauca]

>Wrong Queue VI

That's what I get for writing code before my first cup of coffee