Likely cause of hangs and eventual crashes?

[simuloid]

Hi.  I have a dialog application in Visual C++ 2005 on Windows XP sp 2 that is both displaying information from and sending output to my NI-daq 6251 (USB).

Sometimes when I exit my application, it hangs.  Toggling the power on the daq allows the program to exit.  Doing this causes subsequent instability of the computer, usually causing a "blue screen of death" the next time I try to access the daq.

This problem seems like a deadlock issue.  I am using multiple threads to access the daq, but my shutdown function kills all the threads and then calls stopTask and clearTask on all the tasks that are started on the daq.

Thread 1:  sleep 20 ms, read analog and digital tasks, update the dialog, repeat
Thread 2: (the main thread) if a checkbox changes state, do digital output of the corresponding bit.

My specific questions are:
1) Is there a way to completely reset the daq from software, that clears/resets all tasks?
2) Will stopTask fail if the task is waiting for a sample input?
3) Is there a multi-threaded example?

[Neil_S.]

simuloid,

Thanks for posting to the NI Forums.  Let me see if I can answer your questions.

1.  Is there a way to completely reset the daq from software that clears/resets all tasks?
While it is not possible to clear or stop all running tasks without supplying task handles, it is possible to reset the DAQ device programmatically.  You can do this by calling

int32 DAQmxResetDevice ( const char deviceName[] );

if you are developing a C++ MFC application or by calling

Device::Reset();

if you are using the .NET API.  This will effectively stop any running tasks since the board will no longer be performing an type of acquisition or generation, however it will not free up software resources associated with the task (i.e. the buffers, configuration parameters, etc.).

While performing a reset may resolve the issue you are experiencing, it seems like something more significant is going on here.  From your description it does not sound like you are doing anything that would inherently cause this issue; however, without diving into the code it is hard to say.  I think you are correct that this is some type of deadlock, or race condition.  Is it possible that your threads are being killed at an inopportune time?  Would it be possible to have the shutdown function message the other threads and have the threads end themselves rather than just killing the threads?

2.  Will the stopTask fail if the task is waiting for a sample input?
No, as long as the task is running the stopTask should not fail.  However, I believe if a DAQmxRead is currently running the stopTask blocks until it has finished executing.  This may be where the problem is coming from.  If you kill the thread does it halt the execution in the middle of DAQmxRead?  I am not as familiar with the Visual C++ and am unsure what the repercussions of killing a thread are.  If the DAQmxRead is killed in the middle of execution, I am not sure the behavior of the StopTask is defined.

3.  Is there a multi-threaded example?
I could not find any multi-threaded examples written in Visual C++.  However, one suggestion would be to keep all the code for a specific DAQ task in the same thread.  If you can configure, start, stop and clear the task in a single thread it will remove the possibility for race conditions.  Another possibility would be to block the shutdown function until the threads are in an acceptable shutdown state, but this becomes more complicated.

In summary, I believe the way to solve your issue is to move the stop and clear task functions into the threads that are running their respective task.  I would then have the shutdown function message the threads to tell them to shutdown.  This allows each thread to clean up before exiting and is probably a better practice when programming multi threaded applications anyway.

Hopefully my tips are helpful.  Please let me know if you have further questions or would like additional clarification.  Good luck with your application and have a wonderful day.

Regards,

Neil S.
Applications Engineer
National Instruments