LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

How to exit a lengthy nested thread using global Abort

I made a test machine using LabWin/CVI for both the machine sequence
control and the DAQ. As a result, I have different threads for machine I/O
update (for PLC-like quickness) and process sequencing (which takes about an hour). If the 'PLC' detects a problem
that triggers an abort signal, how can I elegantly exit from my process
sequence when its execution may be several nested layers deep
in a loop or other function? Abort using standard "break" and "return" is cumbersome.
0 Kudos
Message 1 of 3
(3,154 Views)
If you created the threads, you obviously have handles to them. You could KILL the threads and then perform any cleanup required in a seperate thread.
There are SDK functions around to do that.
If you kill a top-level thread, all child threads will halt as well.
Only to be recommended if you know you can tidy up on completion of doing that, i.e. you can free any resources held by those threads after you kill them. (File ptrs, memory etc etc).
Message 2 of 3
(3,154 Views)
Just had a look in the SDK and here are a few ptrs...

---
ExitThread is the preferred method of exiting a thread. When this function is called (either explicitly or by returning from a thread procedure), the current thread's stack is deallocated and the thread terminates. The entry-point function of all attached dynamic-link libraries (DLLs) is invoked with a value indicating that the thread is detaching from the DLL.

If the thread is the last thread in the process when this function is called, the thread's process is also terminated.

The state of the thread object becomes signaled, releasing any other threads that had been waiting for the thread to terminate. The thread's termination status changes from STILL_ACTIVE to the value of the dwExitCode parameter.

Terminating a thread does not necessarily remove the thread object from the operating system. A thread object is deleted when the last handle to the thread is closed.
------
TerminateThread is used to cause a thread to exit. When this occurs, the target thread has no chance to execute any user-mode code and its initial stack is not deallocated. DLLs attached to the thread are not notified that the thread is terminating.

TerminateThread is a dangerous function that should only be used in the most extreme cases. You should call TerminateThread only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination. For example, TerminateThread can result in the following problems:

If the target thread owns a critical section, the critical section will not be released.
If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.
A thread cannot protect itself against TerminateThread, other than by controlling access to its handles. The thread handle returned by the CreateThread and CreateProcess functions has THREAD_TERMINATE access, so any caller holding one of these handles can terminate your thread.

If the target thread is the last thread of a process when this function is called, the thread's process is also terminated.

The state of the thread object becomes signaled, releasing any other threads that had been waiting for the thread to terminate. The thread's termination status changes from STILL_ACTIVE to the value of the dwExitCode parameter.

Terminating a thread does not necessarily remove the thread object from the system. A thread object is deleted when the last thread handle is closed.
-----------
Terminating a Thread
A thread executes until one of the following events occurs:

The thread calls the ExitThread function.
Any thread of the process calls the ExitProcess function.
The thread function returns.
Any thread calls the TerminateThread function with a handle to the thread.
Any thread calls the TerminateProcess function with a handle to the process.
The GetExitCodeThread function returns the termination status of a thread. While a thread is executing, its termination status is STILL_ACTIVE. When a thread terminates, its termination status changes from STILL_ACTIVE to the exit code of the thread. The exit code is either the value specified in the call to ExitThread, ExitProcess, TerminateThread, or TerminateProcess, or the value returned by the thread function.

When a thread terminates, the state of the thread object changes to signaled, releasing any other threads that had been waiting for the thread to terminate. For more about synchronization, see Synchronizing Execution of Multiple Threads.

If a thread is terminated by ExitThread, the system calls the entry-point function of each attached DLL with a value indicating that the thread is detaching from the DLL (unless you call the DisableThreadLibraryCalls function). If a thread is terminated by ExitProcess, the DLL entry-point functions are invoked once, to indicate that the process is detaching. DLLs are not notified when a thread is terminated by TerminateThread or TerminateProcess. For more information about DLLs, see Dynamic-Link Libraries.

Warning The TerminateThread and TerminateProcess functions should be used only in extreme circumstances, since they do not allow threads to clean up, do not notify attached DLLs, and do not free the initial stack. The following steps provide a better solution:

Create an event object using the CreateEvent function.
Create the threads.
Each thread monitors the event state by calling the WaitForSingleObject function. Use a wait time-out interval of zero.
Each thread terminates its own execution when the event is set to the signaled state (WaitForSingleObject returns WAIT_OBJECT_0).
Message 3 of 3
(3,154 Views)