Immediate Timeout When Using Queues, Notifiers, Semaphores or Rendezvous in LabVIEW

Issue Details

I have an application that uses a Queue, Notifier, Semaphore or Rendezvous and occasionally I see an operation (e.g. Enqueue Element, Dequeue Element, Wait on Notification, Send Notification, Acquire Semaphore, etc.) time out in a period shorter than specified. Most commonly this may manifest as a near instantaneous timeout when an infinite timeout is specified. Why am I seeing this behavior?

Solution

National Instruments LabVIEW R&D has identified a bug in the code underlying queues and notifiers that can cause this behavior. This bug can cause calls on the same primitive with different timeouts to honor the timeout value from the previous call rather than the current. This typically manifests when using SubVIs to wrap primitives, but can also occur in a single VI. This issue is addressed in LabVIEW 2014 SP1 f10, LabVIEW 2015 SP1 f7, LabVIEW 2016 f2 and all versions of LabVIEW 2017 and beyond

Case 1:

This example shows the bug reproducing using a single VI. The following code occasionally returns a timeout when the infinite timeout is specified.

Case 2:

Another scenario can be seen in the block diagram of the Acquire Semaphore VI as shipped in vi.lib. If you open the VI, you will notice that this VI is essentially just a wrapper for the enqueue primitive. Because this is a shared reentrant subVI, different call locations may share the same instance. For example, consider the following:

In this case, since we are calling the same primitive from multiple locations, we are in a scenario similar to what we saw above in Case 1. Once again, you may receive periodic timeouts on the infinite case.