Queues and memory allocation

[nathand]

---

@jarcTek wrote:

The "Next Millisecond Multiple" was just for the purpose of showing timing on this example. I thought the "Obtain Queue" would preallocate memory for fixed-sized queues. That is a deal breaker then.

---

I should have also noted that it is possible to force LabVIEW to pre-allocate space for all the items in the queue, as explained here:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/A-Native-Function-to-Preallocate-Memory-in-a-Queue/idc...

However, I still wouldn't count on completely deterministic execution; I don't know what sort of locking is in place around access to the queue, nor whether you might get a slight amount of jitter depending on when the enqueue executes relative to the dequeue. If a standard queue could provide deterministic access, the RT-FIFO wouldn't be needed.

EDIT: although that link does say "a useful trick on RT systems" implying that it might be sufficient to get the determinism you want.

EDIT 2: after a bit more thinking... there really shouldn't be any interference between the enqueue and dequeue operations since you have to be able to enqueue while a dequeue node is waiting.

[jarcTek]

Thank you Nathan.

The preallocation trick sounds like a plausible way around the "memory allocation" issue. Nonetheless, I am still concerned about the way the enqueue/dequeue would behave. Take a look a this a this article. It says:

RT FIFOs execute deterministically in time-critical code and LabVIEW Queues do not. This comes from the fact that Queues use blocking calls when reading/writing to the shared resource while RT FIFOs use non-blocking calls.

As far as I understand this may create priority inversions in my deterministic application, right? 

I still don't see a reason why LabVIEW would not allow the use of classes with RT FIFOs. It would be the same as for clusters, right? If the cluster has a string, path, etc it cannot be used as the type of the RT FIFO. Otherwise, it can be used. Even if the class would not be allowed to have children, it would be very helpful. I have faced this same problem various times.

[Bublina]

---

@jarcTek wrote:

---

@Bublina wrote:

---

@johnsold wrote:

I have no RT experience, so cannot advise you in that regard.  The queue mechanism itself is probably not a problem.  If it is a concern, you may want to put together a realistic test to try to measure the jitter.

Lynn

---

I think, this has been discussed before few times. A bit search results the maximum queue size has to do with the queue logic, not the memory allocations. Some folks did benchmarks to prove it, could not find it.

Not sure about RT and OOP objects.

Hope this helps.

---

I am not sure if I understand what you mean by "A bit search results the maximum queue size has to do with the queue logic, not the memory allocations". Could you explain a little further?

Thank you.

---

Hey, sorry. I was writing it early in the morning 🙂  It means, that a bit of searching revealed, that the maximum queue size has to do... and so on