Strange dequeue timeout behaviour

[Mellroth]

Hi,

I'm using a single element queue as a buffer, where each buffer update involves

1. Dequeue element (ms timeout set to -1)

2. Enqueue new/updated element

The update is done in separate loops or in separate processes.

The strange thing is that the dequeue function sometimes return with timeout = TRUE (but no error).

Since I'm using the ms timeout=-1, this should not be possible?

If I set the ms timeout to a positive value, e.g. 100ms, everything works just fine, no timeouts detected, and buffer handling works as expected.

Has anyone else experienced this?

I'm at home at the moment, but will try to upload a simple test VI on Monday.

/J

[Yair]

The only way I would think that would be possible is if you HAVE wired a timeout into one of the Dequeues. Maybe it's hidden under the function? Maybe you wired 1 instead of -1 or created a 0 constant and didn't change the value?

If that's not the case, then this definitely sounds like a bug.

[Michael Aivaliotis]

Hi,

I'm using a single element queue as a buffer, where each buffer update involves

1. Dequeue element (ms timeout set to -1)

2. Enqueue new/updated element

The update is done in separate loops or in separate processes.

The strange thing is that the dequeue function sometimes return with timeout = TRUE (but no error).

Since I'm using the ms timeout=-1, this should not be possible?

If I set the ms timeout to a positive value, e.g. 100ms, everything works just fine, no timeouts detected, and buffer handling works as expected.

Has anyone else experienced this?

I'm at home at the moment, but will try to upload a simple test VI on Monday.

/J

Please upload a sample VI or image. If this is true then it's a serious bug!!

[Mellroth]

I was about to make a clean test-VI of the bug, but then it suddenly disappeared?

Timeout values were still hard coded to -1, and the only change I made was the handling in case of a timeout and the type of data used in the queues.

I tried to go back to the original code, but the bug was gone.

If it returns I

[LAVA 1.0 Content]

I wonder if this can be somehow related to the notifies problem reported on this forum last week.

[Aristos Queue]

I wonder if this can be somehow related to the notifies problem reported on this forum last week.

I'm pretty sure there's no Notifier bug. The way you guys described it over there, it sounded like correct code. The Notifiers are explicitly not guaranteed to catch every notification. If you post twice and listen once, only the last message gets heard. I didn't say that earlier because there wasn't any code posted to actually inspect, but please don't spread FUD around unless we have something to actually inspect. I close 90% of reported Queue/Notifer bugs as "not a bug" because they're actually programming errors -- someone forgot to wire a terminal or wired it with the wrong wire, or was doing something in two separate loops that wasn't protected, etc. In 8.0 I have one confirmed thread-lock involving Obtain Queue by name in a tight loop with Enqueue. In 8.2, there are no known Queue or Notifier bugs at this time.

Edit: You've posted code on the Notifier bug... I missed that earlier... I'll take a look.

[Aristos Queue]

Edit: You've posted code on the Notifier bug... I missed that earlier... I'll take a look.

Jimi: I looked at your code. WOW. This is an interesting situation. I was knee deep in assembly code, ready to agree with you that it was a bug, when I realized what was going on. In a classic sense, it is not a bug, because the code is operating exactly as intended, and, indeed, exactly as documented. But the consequences in this seemingly simple case are amazing. It might even be considered a bug because we might want to change the documented behavior of the Notifier Wait to account for something like this.

It's going to take me a while to write this up... I'll post it in the other thread later today or tomorrow.

PS: The situation does only affect notifiers, not queues.