This is a good question. You might think that you could do it by throwing an exception from one thread into the other (kind of like the "kill" signal in Unix C or Posix implementations), such that the second thread will then "know" to terminate itself. But you can't do this in Win32 (and not in a CVI app). You might think you could just kill off the second thread with a Win32 SDK call, but if you arbitrarily terminate it (e.g. with the TerminateThread Win32 SDK call) you run the risk of killing the thread when it's in an inappropriate place (such as inside of a critical section) and then you're hosed. Micro$soft calls TerminateThread "a dangerous function" 🙂
So, like the other developer has said, probably the best way is for the second thread to periodically po
ll a flag variable or some other inter-thread communication mechanism to see if the first thread wants it to quit.
What a hassle, huh? This is a well-known weakness of Win32. Some languages/OS's provide for this, but Win32 doesn't, so NI couldn't implement such a facility - you need help from the OS kernel to do it and Win32 just won't do it. So, you have to clutter your code with polling code that's a real annoyance. Even if you know that the second thread is never in a critical section that you've written, if you kill it when it's inside an NI DLL, the same thing might happen, 'cause you don't know how they did things. I've had this happen to me with the NI DAQ DLL. And the same issue exists for one process killing off another - not the critical section issue - but rather shared code and mechanisms - such as DLL's - can get tangled up.