Difference between pthread_exit, pthread_join and pthread_detach

Question

I am complete new to pthreads and I wonder what the exact differences are.

pthread_exit exits a thread. and thus pthread_join will return; However what does detach do that is different from pthread_join?

for instance I create a thread and lets say the thread is finished and I want to completely terminate the thread so I can recreate it later. What is better to use. pthread_join or pthread_detach?

so the order of execution is

pthread_exit();
pthread_join(); or pthread_detach();

?

Solution

pthread_exit is called from the thread itself to terminate its execution (and return a result) early.

pthread_join is called from another thread (usually the thread that created it) to wait for a thread to terminate and obtain its return value. It can be called before or after the thread you're waiting for calls pthread_exit. If before, it will wait for the exit to occur. If after, it simply obtains the return value and releases the pthread_t resources.

pthread_detach can be called from either the thread itself or another thread, and indicates that you don't want the thread's return value or the ability to wait for it to finish. This is useful because otherwise, until you call pthread_join, the pthread_t value remains valid and consumes resources - at the very least, resources to store the return value and tying up one possible value of pthread_t. If you're using pthread_detach, normally you call it from either the new thread or the creating thread as soon as the new thread is created (right after pthread_create).

Comments

[alk]

You might like to read the manual. For pthread_detach: pubs.opengroup.org/onlinepubs/9699919799/functions/…

[alk]

You do not "use pthread_create() on a thread". pthread_create() always creates a new thread. Also, from the docs linked in my previous comment: "... pthread_detach() shall not cause if [the thread] to terminate." You might like to invest some time, some coffees and read this: computing.llnl.gov/tutorials/pthreads

[user3021085]

thank you! I wonder though. Say I have 4 threads. Can I later reuse a thread that I have terminated with pthread_exit and is detached? edit: I mean if I initialize the pthread_t datatype with 4 as the index. Can I later re-create a thread with the same index that was terminated at an earlier step?

[Duck]

What you are asking is if you can reuse the storage space of an element of an array. The answer is of course yes. IOW, threads[index] the memory space yes. The terminated pthread_t value in that space, no. You can't "resuse" a thread id and, in any case, to start a new thread pthread_create is going to return the newly created id to you anyway as in pthread_create(pthreads[index], NULL, whatever, NULL);

[Janaka]

Can some one explain the usage of pthread_datach in a real world example ?

[R.. GitHub STOP HELPING ICE]

@Janaka: A good real-world example I use is when a worker thread has significant costly cleanup work to do before exiting but after it's already produced the result the creator wanted. In that case you would not want to call pthread_join and block progress in another thread until it finishes. You could arrange to have another thread call pthread_join later when it does finish, but this is probably inconvenient, so it's easier to just detach the thread and let its lifetime end when it exits with no need to join it.

[phoenixdown]

Thank you, this answer cleared up a question I had about creating threads when you don't know how many threads you'll create in advance. I wasn't sure how to ensure I had sufficient pthread_t id's, but if I just detach upon creation then I can reuse the single pthread_t id I've declared.

[R.. GitHub STOP HELPING ICE]

@bobo: That's not really a reason to detach threads. You wouldn't call open without storing the resulting file descriptor just because you don't know how many times you're going to open. Instead of trying to have an array for all files you'll open, you'd store the descriptors with the data/task they go with. You should do the exact same thing for thread ids or any other resource identifier - track it with the data structures it's attached to.