probe dequeue

[2verb]

The idea is pretty simple. When I probe an enqueue, I don't want to just see what is being placed on the queue, I want to see where that value is being de-queued.

I have a large legacy project which has a lot of inter-process communication. Queues are used for a lot of this. When I look at code where an element is enqueued, my debugging or code review comes to a screeching halt because I don't know where the data is being dequeued. The project does not use named queues.

This is mostly not a matter of a GUI process communicating with a command and control process in the same VI. It is more of a matter of dynamically loaded drivers passing data back to one of several other processes as conditions change.

I think that I can figure this out with the Trace Toolkit, but it would be cooler if I could just put down a probe and have it tell me where the Dequeue is. (If there were some kind of design time tool that I could use to map the Queue references this would be the coolest of all.)

I know adding a picture helps get the idea across, so here is a fast mock up. Note the red circle in the lower right.

[RavensFan]

I don't see how NI can possibly make your idea work.  For one, while not recommended, it is possible to have multiple dequeue functions for a given queue reference.  What should the probe indicator show?

Probes should show information about the data that is on the wire during execution.  Information that is related to our your program is architected (e.g. where queue references are used) does not belong in a probe indicator.

[2verb]

Possibly the probe indicator would show which ever instance of the dequeue actually dequeued the element that was enqueued. Possibly it would show all the dequeues that have used the same reference as this would be very important information to a developer. It seems like wiring two dequeus to the same reference accidently would be a difficult to debug situation in any moderately sized project.

Let's not get hung up in details. The essence of this idea is to give the developer immediete information about how dequeues and enqueues are related. If you think a probe is inapropriate then what tool do you suggest as a substitute?

As for impossibility, you can already connect these dots by using the Desktop Execution Trace Toolkit which keeps track of enqueue and dequeue and which VIs they happen in. The down side is the bookkeeping to match the Queue reference numbers. Since there is already a computer involved, why not automate this process?

[GregSands]

In a more general sense, it seems that you're asking for a probe that attaches to an item of data, rather than to a wire, and tracks in through the program execution.  I think that's worthy of some discussion.  Here's a few possibilities I could see:

• Imagine if you now put a breakpoint on that DataProbe, and were able to single-step through all computations on that data, but everything else ran normally.
• Or if there was a buffer duplication, that probe was also duplicated, so you could track memory allocations in the debugging process, not just showing the "dots".  That seems useful for not only queues, but also arrays, and objects.
• A "history DataProbe" could retain a buffer of changes to that data, so rather than needing to place probes before and after a computation, it would accumulate a scrollable array of changes.

I could imagine some of those things being very useful in debugging.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.