How do you query a pthread to see if it is still running?

Question

In my destructor I want to destroy a thread cleanly.

My goal is to wait for a thread to finish executing and THEN destroy the thread.

The only thing I found about querying the state of a pthread is pthread_attr_setdetachstate but this only tells you if your thread is:

• PTHREAD_CREATE_DETACHED
• PTHREAD_CREATE_JOINABLE

Both of those have nothing to do with whether the thread is still running or not.

How do you query a pthread to see if it is still running?

Solution 1

It sounds like you have two questions here:

How can I wait until my thread completes?

Answer: This is directly supported by pthreads -- make your thread-to-be-stopped JOINABLE (when it is first started), and use pthread_join() to block your current thread until the thread-to-be-stopped is no longer running.

---

How can I tell if my thread is still running?

Answer: You can add a "thread_complete" flag to do the trick:

Scenario: Thread A wants to know if Thread B is still alive.

When Thread B is created, it is given a pointer to the "thread_complete" flag address. The "thread_complete" flag should be initialized to NOT_COMPLETED before the thread is created. Thread B's entry point function should immediately call pthread_cleanup_push() to push a "cleanup handler" which sets the "thread_complete" flag to COMPLETED.

See details about cleanup handlers here: pthread cleanup handlers

You'll want to include a corresponding pthread_cleanup_pop(1) call to ensure that the cleanup handler gets called no matter what (i.e. if the thread exits normally OR due to cancellation, etc.).

Then, Thread A can simply check the "thread_complete" flag to see if Thread B has exited yet.

NOTE: Your "thread_complete" flag should be declared "volatile" and should be an atomic type -- the GNU compilers provide the sig_atomic_t for this purpose. This allows the two threads consistent access the same data without the need for synchronization constructs (mutexes/semaphores).

Solution 2

pthread_kill(tid, 0);

No signal is sent, but error checking is still performed so you can use that to check existence of tid.

CAUTION: This answer is incorrect. The standard specifically prohibits passing the ID of a thread whose lifetime has ended. That ID might now specify a different thread or, worse, it might refer to memory that has been freed, causing a crash.

Solution 3

I think all you really need is to call pthread_join(). That call won't return until the thread has exited.

If you only want to poll to see whether the thread is still running or not (and note that is usually not what you should be wanting to do!), you could have the thread set a volatile boolean to false just before it exits... then your main-thread could read the boolean and if it's still true, you know the thread is still running. (if it's false, on the other hand, you know the thread is at least almost gone; it may still be running cleanup code that occurs after it sets the boolean to false, though, so even in this case you should still call pthread_join before trying to free any resources the thread might have access to)

Solution 4

There is not fully portable solution, look if your platform supports pthread_tryjoin_np or pthread_timedjoin_np. So you just check if thread can be joined (of course created with PTHREAD_CREATE_JOINABLE).

Solution 5

Let me note on the "winning" answer, which has a huge hidden flaw, and in some contexts it can lead to crashes. Unless you use pthread_join, it will coming up again and again. Assume you are having a process and a shared library. Call the library lib.so.

1. You dlopen it, you start a thread in it. Assume you don't want it join to it, so you set it detachable.
2. Process and shared lib's logic doing its work, etc...
3. You want to load out lib.so, because you don't need it any more.
4. You call a shutdown on the thread and you say, that you want to read a flag afterwards from your lib.so's thread, that it have finished.
5. You continue on another thread with dlclose, because you see, that you have saw, that the flag is now showing the thread as "finished"
6. dlclose will load out all stack and code related memory.
7. Whops, but dlclose does not stop threads. And you know, even when you are in the last line of the cleanup handler to set the "thread is finished" volatile atomic flag variable, you still have to return from a lot of methods on the stack, giving back values, etc. If a huge thread priority was given to #5+#6's thread, you will receive dlclose before you could REALLY stop on the thread. You will have some nice crashes sometimes.

Let me point out, that this is not a hipothetical problem, I had the same issue on our project.

View more solutions