The following program shows that we can use return
or pthread_exit
to return a void*
variable that is available to pthread_join
's status variable.
Should there be a preference for using one over the other?
Why does using return work? Normally we think of return putting a value on the stack but since the thread is completed the stack should vanish. Or does the stack not get destroyed until after pthread_join
?
In your work, do you see much use of the status variable? It seems 90% of the code I see just NULLs out the status parameter. Since anything changed via the void*
ptr is already reflected in the calling thread there doesn't seem much point to returning it. Any new void*
ptr returned would have to point to something malloc
ed by the start thread, which leaves the receiving thread with the responsibility to dispose of it. Am I wrong in thinking the status variable is semi-pointless?
Here is the code:
#include <iostream> #include <pthread.h> using namespace std; struct taskdata { int x; float y; string z; }; void* task1(void *data) { taskdata *t = (taskdata *) data; t->x += 25; t->y -= 4.5; t->z = "Goodbye"; return(data); } void* task2(void *data) { taskdata *t = (taskdata *) data; t->x -= 25; t->y += 4.5; t->z = "World"; pthread_exit(data); } int main(int argc, char *argv[]) { pthread_t threadID; taskdata t = {10, 10.0, "Hello"}; void *status; cout << "before " << t.x << " " << t.y << " " << t.z << endl; //by return() pthread_create(&threadID, NULL, task1, (void *) &t); pthread_join(threadID, &status); taskdata *ts = (taskdata *) status; cout << "after task1 " << ts->x << " " << ts->y << " " << ts->z << endl; //by pthread_exit() pthread_create(&threadID, NULL, task2, (void *) &t); pthread_join(threadID, &status); ts = (taskdata *) status; cout << "after task2 " << ts->x << " " << ts->y << " " << ts->z << endl; }
With output of:
before 10 10 Hello after task1 35 5.5 Goodbye after task2 10 10 World
RETURN VALUE The pthread_exit() function cannot return to its caller.
On return from a successful pthread_join() call with a non-NULL value_ptr argument, the value passed to pthread_exit() by the terminating thread shall be made available in the location referenced by value_ptr. When a pthread_join() returns successfully, the target thread has been terminated.
The pthread_exit() function terminates the calling thread and makes the value value_ptr available to any successful join with the terminating thread. Any cancellation cleanup handlers that have been pushed and not yet popped are popped in the reverse order that they were pushed and then executed.
If you want to return only status of the thread (say whether the thread completed what it intended to do) then just use pthread_exit or use a return statement to return the value from the thread function.
(1) In C++ code, using return
causes the stack to be unwound and local variables destroyed, whereas pthread_exit
is only guaranteed to invoke cancellation handlers registered with pthread_cancel_push()
. On some systems this mechanism will also cause the destructors for C++ local variables to be called, but this is not guaranteed for portable code --- check your platform documentation.
Also, in main()
, return
will implicitly call exit()
, and thus terminate the program, whereas pthread_exit()
will merely terminate the thread, and the program will remain running until all threads have terminated or some thread calls exit()
, abort()
or another function that terminates the program.
(2) The use of return
works because the POSIX specification says so. The returned value is stored in a place where pthread_join()
can retrieve it. The resources used by the thread are not reclaimed until pthread_join()
is called.
(3) I never use the return value of a thread in raw POSIX threads. However, I tend to use higher level facilities such as the Boost thread library, and more recently the C++0x thread library, which provide alternative means for transferring values between threads such as futures, which avoid the problems associated with memory management that you allude to.
I think that return
from the start_routine
is preferable, because it ensures that the call stack is properly unwound.
This is even more important for C than C++ since it doesn't have the destructor magic that cleans up the mess after preliminary exits. So your code should go through all final parts of routines on the call stack to do free
s and alike.
For why this works, this is simple
If the start_routine returns, the effect shall be as if there was an implicit call to pthread_exit() using the return value of start_routine as the exit status
For my personal experience I tend to not use the status of terminated threads much. This is why I often have the threads started detached
. But this should depend much on the application and is certainly not generalizable.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With