pthread_exit() doesn't have the mechanism of stack unwinding. Can we completely avoid using pthread_exit() in C++? Or, are there any cases where we require this API instead of return from thread function in C++?
pthread functions are platform-specific. C++ has its own platform-independent thread API. It doesn't have a function that would correspond to pthread_exit. Use the std::thread API and don't worry about pthreads.
If you need to terminate a thread in the middle without explicitly returning all the way up to the thread starting function, throw an exception and catch it in the starting function. This will unwind the stack properly.
To quote from the documentation:
An implicit call to pthread_exit() is made when a thread other than the thread in which main() was first invoked returns from the start routine that was used to create it. The function's return value serves as the thread's exit status.
Which means that you don't need to call it yourself unless you want to avoid returning from that function (perhaps naked functions, or interrupt handlers or something really low level).
Related
I want to check a global bool value in my thread whenever necessary:
If it's true the thread should exit, and the thread should continue if it's false.
While checking, I could be inside a single function or I could be within a nested function. I need to ensure that I return to the main function first, then return 0 in the main function, which seems very stupid.
So the only way I can think of is to throw an exception when the condition is fulfilled and then catch it at the end of this thread, so that all the elements are destructed correctly.
So is there a more standard way in C++ language to do this? How do you exit a thread while you are in a nested function?
Your approach is fine. Compared to the costs of thread creation and destruction, throwing an exception is negligible.
If for some reasons you aren't allowed to use exceptions:
Check that signaling variable several places in your code. Note that regular code runs pretty damn fast so you only need these checks inside/before long calculations (loops) or IO operations that could block. Make sure the rest of the code doesn't depend on the results of some unfinished calculations.
Use a coding style where you always return an error code from every function (at least for this thread).
There are system-specific functions like ExitThread and pthread_exit but they are not recommended to use because they will result in memory leak: destructors will not be called, including CRT/stdlib internal objects if the thread was created using std::thread.
So the answer is: no, there is no standard way to exit a thread in C++. Just consider the thread as a regular function.
For std::thread t(foo);, does it ever make sense to have a foo [[noreturn]] () {...}? For ex. for a detached thread (Used as a sort of daemon until the apps completion)?
Thread does not make a new process and does not use fork or exec, it makes a thread which should definitely eventually return. If your thread function never returns you'll hang on std::thread::join
Would it be of any benefit on gcc/clang to mark the function used for the thread with [[noreturn]]?
Thread functions normally do return. So no, they must not be marked with [[noreturn]].
Unless they are coded to have an infinite loop, block forever, or call functions that terminate the thread or the process. In that case you might like to mark them as noreturn.
Note, that if you are using low-level functions like pthread_create to create a thread or other function which definition is not available at compile time, noreturn attribute will not have any effect on the code that invokes your function through a pointer.
The return value of a thread function of a detached thread is ignored.
I expect it (std::thread construction) to be some kind of fork + execve variation on my system and once successful it would have nothing to return to.
std::thread creates a separate thread (within the same process). fork + execve work on multiple processes.
Would it be of any benefit on gcc/clang to mark the function used for the thread with [[noreturn]]?
Only if the function you pass to std::thread does not return (that is, if the function calls std::exit, std::terminate, throws in all cases or starts an infinite loop, and so on).
I'm used to work with good old WinAPI call CreateThread(), and check thread's status using the waiting function, e.g WaitForSingleObject(), Once thread thread is signaled with WAIT_OBJECT_0, i close it using CloseHandle().
Recently I've decided to move to beginthread and somehow avoid the risks of uninitialized crt and accidental memory leaks that may happen.
Doing that got me confused.
What's the exact purpose of endthread()? why when i call CloseHandle() in the main function, after thread's execution, CloseHandle() crashes with invalid handle?
Should i ever close the handle returned by beginthread?
endthread, As i understood is invoked automatically by the thread once my function goes out of scope, so should i call it anyway just before i get out of scope?
According to msdn, endthread already calls CloseHandle() 1.From where does the thread obtain a reference / instance to its handle. 2. If i do insist on using endthread(), should it be the last command in the thread?
thanks
EDIT: MSDN paper describing the leaks, here.
As stated in the comments by David Hefferman you can simply change your code back to using CreateThread. The Visual C++ runtime (CRT) will automatically initialize the CRT's per thread data the first time you use a function that uses the per thread data.
The CRT will also automatically free the per thread data when a thread ends, so using CreateThread won't cause memory leaks. There is one exception, if all of the following conditions are true then per thread data isn't automatically freed:
You're building an executable, not a DLL
You're linking against the static version of the CRT library (LIBCMT.LIB) instead of the DLL version (MSVCRT.LIB)
The executable you built is run under Windows XP (or an earlier version of Windows).
Note that even if all this true in your case, the memory leak isn't going to be significant unless you're creating a long lived application that creates and destroys hundreds of thousands of threads over its life time.
If you still want to use the CRTs thread creation functions (_beginthread/_beginthreadex) you should follow these guidelines:
Never use the handle returned by _beginthread. With _beginthread the thread handle is automatically closed when the thread exits, which can potentially happen before _beginthread even returns. You can't use it with WaitForSingleObject safely because the thread might have already exited before you call this function. If you want to use the thread handle for anything use _beginthreadex instead.
You should never close the handle returned by _beginthread. The CRT will do it automatically, and as described in the previous point, may do so before you have chance to.
You should always close the handle returned by _beginthreadex when you no longer need it. The CRT won't do this automatically for you, so it's your own responsibility.
Don't call _endthread or _endthreadex unless you want to quickly and abnormally terminate the thread. While the CRT will free its own per thread data, none of the C++ destructors for any of the thread's objects will be called. It behaves similarly to how _exit ends the process without calling destructors.
The normal means of ending a thread should be by returning from the function passed as an argument to _beginthread or _beginthreadex. This will result in C++ destructors being called as a normal part of the function return.
If I don't care about the return status of my thread, would I need to have a pthread_exit?
I'm wondering if there might be some subtle resource problems associated with not calling pthread_exit in my datached pthreads.
Thanks.
The purpose pthread_exit() is to return the exit code if any other threads that joins.
From the manual:
Performing a return from the start function of any thread other than the main
thread results in an implicit call to pthread_exit(), using the function's
return value as the thread's exit status.
So, it makes no difference if you don't use it.
You don't have to call pthread_exit(). Returning from the thread function would work equally well, and will not leak any resources (of course, you still have to ensure that your code doesn't have any leaks).
I need to make use of thread-local storage in a cross-platform project. Under *IX I am using pthreads and can avoid memory leaks thanks to the nice destructor function pointer passed as the second argument to pthread_key_create, but in Windows TlsAlloc has no such thing. Nor can I find a general place where any function is called on thread exit (otherwise I would homebrew some list of function pointers that get called at exit).
As it stands it seems that I have basically a situation where in order to actually use thread local storage I need to allocate my own space on the heap and pass a pointer to TlsSetValue, but if the thread exits ... I have no way of ensuring the memory was freed (other than someone explicitly calling TlsGetValue and delete/free/HeapFree/etc at the end of the thread function.
Does anyone know of a better way?
You can get yourself a nice "finalizer" to get rid of thread-specific resources, even if the thread is terminated: use RegisterWaitForSingleObject to wait on a copy (via DuplicateHandle) of the threads' handle - you have to use the cloned handle, cause registered waits can't handle handle {no pun intended} closing.
Use a heap allocated structure/record to hold the finalized resources, the handle waited for and the wait handle itself, cause the finalizer will run in the system threadpool, NOT the finalized thread (which will be already dead by the time). And don't forget to finalize the finalizer :)
The entry point of a DLL (DLLmain) is called on thread exit with a reason code of DLL_THREAD_DETACH. It is fairly straightforward to write a DLL that keeps track of functions to call on thread exit.
Alternatively, use Boost.Thread and the boost::this_thread::at_thread_exit function to register a function to be called on thread exit, or use boost::thread_specific_ptr to wrap the TLS usage entirely.