Programming

Suppose I declare

pthread_t clear_thread;

and then

pthread_create(&clear_thread, &detach, clear_message, this);

the thread is supposed to go away, perform the service it is intended to procide, and then kill itself.

A little while later, I require this service again, so I say

pthread_create(&clear_thread, &detach, clear_message, this);

Now if, whether by accident or design, the first thread is still running, what is supposed to happen? The man pages seem to be silent on this issue (one would have hoped that creating a new thread on an already running identifier would return an error, but it seems not to be so).

So, are there now two threads running? and if I try to do a pthread_kill on it which thread (or both?) gets killed?

And, for that matter, is there any way to tell whether a thread that I have created is still running? Or do I have to declare a variable to keep track of that myself?

I suspect that the answer is that I have made a programming blunder by allowing this situation to arise, but it is an easy mistake to make, especially if you did not foresee the necessity to demand this service frequently (I got into this mess because my progma ran amok and started demanding service continuously, and eventually I think I got into some deadlock). But if that is the answer, then I suspect it is a bug in the design of the pthread system - or is it a feature?

For the record, I am trying to put messages up on an LCD, and this thread is created to take them down again after 30 seconds, or when the user acknowledges them, or whatever, and there are associated threads for putting the backlight on, and turning it off after a while.

Several points. Thread synchronization ( what you are asking about)

Code:

pthread_t tid;
pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
pthread_create(&tid, &attr, some_func, (void *)args);

This creates a detached thread - one that goes away when it hits a pthread_exit() statement or a return statement at the end of some_func();

The default pthread_create() call, by default, in most UNIXes, creates a joinable thread.
Not a detached thread like above.

So you do this for each thread:

Code:

pthread_t tid;
pthread_create(&tid, &attr, some_func, (void *)args);
pthread_join(tid, NULL);

The code blocks on pthread_join() until the child thread hits return or pthread_exit().
One type of thread you wait for (join) the other you do not care about.

You need to decide which one you want to use, there really aren't a lot of other choices.
You can set a global variable:

Code:

volatile int i_am_done=0;

and change the variable to let the parent know a detached thread completed.
Protect the volatile int with a mutex: pthread_mutex_lock & pthread_mutex_unlock calls, whenever you set or look at the variable.

And. pthread_kill is not always a great choice. All it does is to direct the signal to the thread. Example: SIGKILL (kill -9) destroys the entire process because the effect of the signal is to nuke the entire process. So signals do not behave the way you might believe a priori.

Indeed, but the pthreads in my example were created as detached (I showed a parameter '&detach' which was intended to give a strong hint to that effect).

And I agree that pthread_kill has to be used with caution, but in my case the threads were all 'sleep'ing, so I killed them with SIGALRM and they woke up and proceeded on their way, which was to kill themselves.

But you have not answered my main question, which was what happens (or is supposed to happen) if you create another thread on the same tid variable before it has died. It may be (indeed probably is) bad practice, but bad practice (aka s**t) happens, and the pthread system offers no help in avoiding it.

And if I need to know whether the thread on some tid is still running, how can I tell? Do I have to create some sufficiently global variable and keep track of it myself (which is what I have done) is is there some way I can ask?

It seems that what I need to do is discover whether a thread is still running on the tid, and then either arrane to kill it, or else to persuade the existing thread to take on new responsibilities. When I first wrote this code, I did not consider this possibility and it worked fine until things started to happen too faat.