How to kill a thread nicely

I have a program with a few threads, and it is possible for one of the threads to get stuck, due to a failure to communicate with some hardware. If this happens, I would like to quit the thread and restart it. I have looked up pthread_exit and it seems to do what I want, but I am not sure whether it is ok to simply restart the thread, or if it will consume more memory than expected if this is done potentially many times. If anyone could give me more information about this beyond that contained in the man page, or suggest an alternative method to kill the thread, it would be appreciated, and please note that I do not have a degree in computer science. If it helps, I am using pthread under Ubuntu. Thank you.

Originally Posted by doublec16 I have a program with a few threads, and it is possible for one of the threads to get stuck, due to a failure to communicate with some hardware. If this happens, I would like to quit the thread and restart it.

Does the thread block in some syscall? Usually that is what getting stuck means.

If yes, then the thread may need some external assistance. Install a dummy signal handler -- it does not need to do anything, the important bit is that the signal is delivered to the user code -- and send that signal to the stuck thread using pthread_kill(), interrupting the syscall. But before that, cancel the same thread using pthread_cancel(). The thread will be terminated (with PTHREAD_CANCELED as the exit status) at the next cancellation point. The man 7 pthreads man page will tell you which functions are cancellation points, but you can add explicit ones yourself simply by calling pthread_testcancel().

If the thread does not block in some syscall, but simply observes that it should exit, then calling pthread_exit() at that point will also terminate the thread just fine.

Originally Posted by doublec16 I have looked up pthread_exit and it seems to do what I want, but I am not sure whether it is ok to simply restart the thread, or if it will consume more memory than expected if this is done potentially many times.

All data structures and memory created internally by the pthreads library for that thread is released automatically. Per-thread variables (static __thread variables, and any local variables in the functions the thread was running), as well as the stack the thread used, are all also released automatically.

Memory allocated by the thread, file descriptors, sockets, directory streams, and other such resources are not automatically released. If the thread has allocated memory or opened or acquired such resources, they will stay allocated and open. It will be your responsibility as a programmer to remember to release such resources. In particular, "but I don't have any references to the resource left; they were all local for the thread!" is no excuse; it is your task to make sure those resources are released, or terminating the thread will indeed leak memory and/or other resources.

A simple way to clean up any leftover state like file descriptors or dynamically allocated memory (that is not accessible to other threads and should be released if the thread gets cancelled), is to use pthread_cleanup_push() and pthread_cleanup_pop().

For very complex code with complicated dynamic memory management, I recommend using a pool-based custom memory allocation scheme. Basically, you write your own malloc() and free() used by your thread functions, that manage the allocations as a per-thread pool or chain, so you can release the entire pool or chain at once -- for example, if the thread was cancelled.

I want to do some thread programming and I dont know where/how to start with.Can anyone here guide me about how do I go about doing this.

Originally Posted by Ajit Gunge I want to do some thread programming and I dont know where/how to start with.Can anyone here guide me about how do I go about doing this.

Please do not hijack threads; your question has nothing to do with this thread.

Besides, plugging pthreads tutorial example into a web search provides a lot of pages for pthreads programming (assuming that is what you refer to; you could be talking about any programming language, I suppose). Only you can tell which ones are good for you, because they assume varying levels of existing programming skill, and have different approaches. The Lawrence Livermore National Laboratory one and YoLinux one look particularly interesting, so I guess you could start with those.

I suggest that your thread should be the sovereign master of its own affairs. If there's the possibility that a call could "get stuck," then the thread itself should set a timer to guard against that possibility. If the timer goes off, the thread's own signal-handler could for instance terminate the thread ... after perhaps notifying some other process of its predicament.

This is IMHO the only reliable way to close a nest of vexing (and non-reproducible) timing holes. Never hold a gun to the head of another process or thread.

Originally Posted by sundialsvcs If there's the possibility that a call could "get stuck," then the thread itself should set a timer to guard against that possibility.

I agree; that is how I handle my own threads. It is a good thing you took the time to point out the weakness in the OP's original approach. Thank you, sundialsvcs.

I prefer to use timer_create() and timer_delete() to manage POSIX per-process timers for this. I use timer_settime() to set an initial timeout, followed by rapidly repeating timeouts (10ms typically), with expiration via a signal to a specific thread (SIGEV_THREAD_ID; Linux-specific).

Whenever you have a blocked syscall interrupted by a signal, it is very easy to accidentally miss the signal delivery. For example, instead of getting -1 with errno set to EINTR from a read or write function, the function may just return a short count. The more complex cases tend to have very short intervals (almost impossible to notice or understand by just reading the code), during which the signal delivery is missed, causing the code to block when it should not. This is common, and looks like a stuck thread. Using a POSIX per-process timer with thread-specific signal delivery, and rapid repeat after the expiry, makes sure the timeout signal is not missed! It is very easy to use, too.

If you follow the same path, keep in mind that while the signal is delivered to a specific thread in Linux (and will therefore interrupt that thread), each signal handler is set for the entire process. In other words, you'll need to dedicate one signal number for timeouts. The handler for that signal can have an empty body; it is enough to have the signal delivered, the signal handler does not need to do anything.

With very little work, you can quite easily create a minimal library that handles all the work in the background, and maintains a per-thread "stack" of timeouts. If you release all timeouts scheduled after the released one too, you can have very lax rules, basically garbage-collecting un-disarmed timeouts. I thought about writing one a couple of years ago when I last needed many timeouts, but since I ended up needing them only in one thread workers, it was easier to just code the timeouts in the thread handler (instead of a separate library).

Hope you find this useful,