more questions about callbacks...

[mzimmers]

I'm trying to get a good conceptual understanding of callbacks and threads within the context of CVI. I've read the help, but it leaves me with some questions:

1. when a control triggers a callback, does it execute in another thread?

2. when a timer triggers a callback, does it execute in another thread?

3. under what if any circumstances do callbacks interrupt one another?

On a related note, are there any resource locks/mutexes/flag systems within CVI that aren't thread-related? I'm trying to chase down some unexplainable behavior that I think is related to a conflicting socket reads.

Thanks.

[SerJames]

Hi mzimmers,

CVI's default behavior is to run everything single threaded, within the UI Thread. That will include control and timer trigger callbacks. While the callbacks are queued asynchronously the system will still run them synchronously. That is actually the behavior that takes place when you call ProcessSystemEvents()It essentially runs a while loop and executes all of the callbacks in the queue. This behavior also will prevent callbacks to interrupt one another. Unless programmed otherwise, CVI takes a relatively straight forward approach to its callback handling.

When it comes to locks and mutexes, I cannot think of any case where they would be needed or used in a sequential, single threaded system.

I guess the million dollar question is what sort of behavior are you seeing with your application? That would likely shed more light on what sort of answer you are looking for and we can proceed from that point.

EDIT: I forgot to mention, that if you have not had a chance to review this doc, it gives a good high level overview of multithreading and using it within CVI. It may not be completly applicable but really offers some good basic documentation on the process and insights on making good multithreaded programs. May be worth a read.

http://www.ni.com/white-paper/3663/en

Regards,

[mzimmers]

Hi, SerJames -

Thanks for the response. Here's my app in a nutshell: a timer with a CB that wakes up several times a second, sends data requests via TCP, reads the responses, and plots data. I have a few controls that set a global variable. When the global variable is set, the CB doesn't do anything. Then the controls can modify other globals that tune the timer CB parameters.

I set a "ready" variable at the top of the timer CB, and clear it when I'm done. The callbacks all check this variable before doing anything.

The app is a bit hard to debug because I'm seeing different behavior when I step through the debugger vs. letting it run. Hence, my concerns about asynchronous behavior. It's hard to know exactly, but I thought my TCP input was getting overwritten. I suppose it's possible that my read loop just isn't fully debugged.

[SerJames]

Hey mzimmers,

If you are seeing different results from debugging vs run-time, I would agree that it could be a async issue. I am not quite sure I fully understand what issues you are seeing. Are you actually seeing different read results as the driving issue? One thing to make sure is that you are fully reading off your tcp buffer. You could look to add in waits into your program to see if simply adding a delay in your tcp reads helps smooth things out and ensure that everything is received.

Regards,