pthread: method to signalize if thread is running/exited?

[davenull]

heya,

ie there a way to see from 1 pthread task (ID=pthread1, name=pthread1name ) if another pthread task (ID=pthread2, name=pthread2name) is running/sleeping/exited/halted/killed or what ever?
setting a proprietary semaphore by each running task is perhaps a little shaky in case of unexpected stop by accident or if an external kill task happened ...

[davenull]

no idea - or no way ?

[Paeryn]

If a child thread has unexpectedly quit (crashed) then it's likely to kill the whole process anyway. No program should be randomly killing off your threads, if they do they should expect to bring down the owning process.

If the thread quits normally then you're in the perfect position to know. Set a variable that is accessible to both the main thread and the child thread to say "hey, I've finished" which your main thread checks for.

Edit:
If you really want to know about a thread's state you can always read it's status in /proc you'll need the process id and the thread id
process id is easy

Code: Select all

pid_t pid = getpid()

thread id (from within the thread - needs #include <sys/syscall.h>)

Code: Select all

pid_t tid = syscall(SYS_gettid);

Then read the file /proc/pid/task/tid/status. e.g. pid = 4130, tid = 4131, it says this thread is sleeping (pth is the name of the process).
cat /proc/4130/task/4131/status

Code: Select all

Name:   pth
State:  S (sleeping)
Tgid:   4130
Ngid:   0
Pid:    4131
PPid:   3654
TracerPid:      0
Uid:    1000    1000    1000    1000
Gid:    1000    1000    1000    1000
FDSize: 256
Groups: 4 20 21 24 25 26 27 29 30 44 46 100 108 110 113 114 116 120 1000 
VmPeak:    10228 kB
VmSize:    10228 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:       344 kB
VmRSS:       344 kB
VmData:     8376 kB
VmStk:       136 kB
VmExe:         4 kB
VmLib:      1680 kB
VmPTE:        20 kB
VmSwap:        0 kB

[davenull]

thank you,
but my question was about a task among others in the same program, e.g.

Code: Select all

    pthread_t thread0, thread1, thread2, thread3, thread4, thread5;
    struct  sched_param  param;

    pthread_create(&thread0, NULL, thread0Go, NULL);     // lowest priority task: screen output
    param.sched_priority = 10;
    pthread_setschedparam(thread0, SCHED_RR, &param);
   
    pthread_create(&thread1, NULL, thread1Go, NULL);     // low priority: keyboard monitoring (stop program)
    param.sched_priority = 20;
    pthread_setschedparam(thread1, SCHED_RR, &param);
   
    pthread_create(&thread2, NULL, thread2Go, NULL);     // medium  priority: motor control
    param.sched_priority = 40;
    pthread_setschedparam(thread2, SCHED_RR, &param);
   
    pthread_create(&thread3, NULL, thread3Go, NULL);     // highest priority: encoder reading     
    param.sched_priority = 80;
    pthread_setschedparam(thread3, SCHED_FIFO, &param);
   
    pthread_create(&thread4, NULL, thread4Go, NULL);     // medium priority:  UART comm   <<< test !!
    param.sched_priority = 40;
    pthread_setschedparam(thread4, SCHED_FIFO, &param);
   
    pthread_create(&thread5, NULL, thread5Go, NULL);     // medium priority: navigation
    param.sched_priority = 40;
    pthread_setschedparam(thread1, SCHED_FIFO, &param);

This current setup has to be extended by a subsumption "behaviour" architecture of even more tasks, and some will run repetitively, and some only intermediately, and sometimes it might happen that a motor control task will need to know if another motor control task is still running or already has finished, to afterwards start a new action.
Also it might happen that 1 task (1) has to be stopped or killed by another task (2) of emergency stop purposes, but a task (3) will need to run task 2 simultaneously or exclusively alternatively so it will have to know about it's runstate.

So a syscall is actually not what I would need, and my program also don't know about pid_t tid or SYS_gettid, so then I would need something like

int i = thread.runstate(thread5);

[Paeryn]

If one of your child threads needs to kill another then you it should send a message or signal to it telling it to quit, it hasn't happened behind your back and you're in control of what threads are running.

Your thread should be looking out for such a quit message / signal and quit gracefully when it receives it. And since all threads share the same memory space you can easily have all threads knowing whether any of the other threads are running.

[davenull]

yes, by semaphores it would work perhaps as a workaround, but that might be shaky in some cases.
But more precisely it would be if one could get either thread runstates by a function call, returning the thread's runstates explicitely.

[Paeryn]

In what case would it be shaky? If it is then you're doing something wrong.

Your process is in control of its own threads, there's basics for starting, signaling, cancelling and joining. Pretty much everything else is up to you to implement according to what you want to do and how. If your process doesn't have any way of knowing whether a thread that it owns is running or not then you haven't implemented it properly. Why do you need to ask the system to tell you what you should already know?

[davenull]

what is signaling?
I have started the single tasks in main, but I don't know at which time exactly which one will be halted or re-started during runtime.
So I assumed it should be possible to poll a scheduler list or what ever to find out if a certain pthread task still running or sleeping or halted.

[Paeryn]

what is signaling?

Signalling is where one process/task signals another. Your process / thread can either regularly check to see if a signal has been received or you can set handlers that will be called automatically whenever a certain signal is received. Things like killing processes (sending SIGKILL) and pausing (sending SIGSTOP / SIGCONT) are all done via signalling. Pressing CTRL-C on the command line to stop a program really just sends the program a SIGINT signal.

I have started the single tasks in main, but I don't know at which time exactly which one will be halted or re-started during runtime.
So I assumed it should be possible to poll a scheduler list or what ever to find out if a certain pthread task still running or sleeping or halted.

How do you mean halted and re-started? A thread generally runs until it finishes, it might get put to sleep if it waits on something like I/O or expressly calls sleep() or such like. You could send a SIGSTOP to a thread to stop it being scheduled but since you've said you don't know what signalling is I take it you're not doing that. A thread can't be re-started unless you mean continuing a stopped thread (stop here means to temporarily prevent linux from running the thread, not the thread finishing), once a thread finishes it's over, you have to start a new one to run it again. And unless you explicitly run a thread detached then you should be joining with a thread once it has finished (or when you want to wait for it to finish), when you do that you know the thread has definitely finished as pthread_join() doesn't return until the thread exits.

You'll probably want to use the pthread_mutex_* functions to make sure only one thread at a time can read / modify shared data.

There's absolutely no reason for you to not know what your threads are doing at any time. You can't ask the system if thread X is still running because if that thread has in the mean time finished and another (different) thread has been started afterwards then system is allowed to re-use the same ID, then what you think is your thread X could now be thread Y. The only way for you to know is by keeping track yourself. Also if a thread has finished (and has been joined if it wasn't detached) and no new thread has been assigned to that ID then you're not allowed to reference it, doing so is undefined behaviour and could crash your process.

[davenull]

thank you,
actually I am keeping track of the threads by using semaphores:
a thread10 (thread10name) has it's own semaphores (e.g., runstatethread10) which the thread itself sets to 1 at it's very start and which it sets to 0 before it exits, shortly before "return NULL" or whatever.
But I wanted to abandon that and replace it by polling sort of an intrinsic automatic check_threadstate function.

Nevertheless, the signalling thing I didn't know so far. SIGSTOP sounds interesting and very useful indeed. Do you have a link to a very short and very understandable tutorial for absolute newbies which explains just it's handy and convenient usage inside of a C/C++ program by short practical code examples?

Killing a thread ( pthread_cancel(threadID)) is only intended in case of urgent emergency reasons after a certain latency when a safe stop failed.

About mutexes: so far I'm using wiringPi piLock (int keyNum) / piUnlock (int keyNum) ; the native mutex functions are too complicated for me to use, I don't understand them yet.

for start/stop a task:
In my former programming environments (VMs, akin to Java) I had simple functions like
starttask (taskname)
and
stoptask (taskname)
which I could use arbitrarily to start, stop (prematurely), and restart any task at any time out of other tasks. I now try to mimic that functionality.

[davenull]

all I could find out about SIGSTOP so far is that it's used as a command line command, e.g.,
kill -SIGSTOP [pid]
kill -SIGCONT [pid]

But that's not what I'm looking for, I need a C/C++/POSIX command using the thread (task) IDs in my program, e.g., initialized by
pthread_t thread0, thread1, thread2, thread3, thread4, thread5; // task IDs

So I need a way to pass the task IDs
thread0, thread1,... thread5
to the desired function in order to
a) stop a task out of another task in case of need and
b) get information about it's current runstate out of any other running task.

starting or restarting a task is currently done by
pthread_create(&thread0, NULL, thread0Go, NULL); // ... , thread1,...thread5

[PeterO]

man 3 pthread_kill

[davenull]

pthread kill or perhaps pthread_cancel(threadID) is only intended in case of urgent emergency reasons, and is already what I use then.

My question was more about how to poll the current runstate, both of continuously running threads (perhaps being prematurely terminated) and limited, temporarily running threads (e.g. started for PID control until a target has been reached, then terminated by themselves, or running to keep close to the target until being stopped externally by environmental circumstances and events, voltage drop, tilt, longer lasting stalling, a.s.o.)

[PeterO]

pthread kill or perhaps pthread_cancel(threadID) is only intended in case of urgent emergency reasons,

No it isn't. It is used to send ANY signal to a thread. You can use SIGUSR1 and SIGUSR2 for what ever you want, it doesn't have to be an urgent emergency.

My question was more about how to poll the current runstate, both of continuously running threads (perhaps beeing prematurely terminated) and limited, temporarily running threads (e.g. started for PID control until a target has been reached, then terminated by themselves, or running to keep close to the target until being stopped externally by environmental circumstances, tilt, longer lasting stalling, a.s.o.)

No it wasn't . You said

I need a C/C++/POSIX command using the thread (task) IDs in my program .....
to the desired function in order to
a) stop a task out of another task in case of need

pthread_kill does this. You can send a SIGUSR1 to a thread and get the handler to do what ever you want in the thread when it is received. You could get it to update it's status in a shared structure (though it will need some synchronisation or locking).

PeterO

[davenull]

sorry, it was perhaps a little unspecific how I expressed it:
by

pthread kill or perhaps pthread_cancel(threadID) is only intended in case of urgent emergency reasons,

I meant : I personally want to do it only in these cases.

OTOH, by

My question was more about how to poll the current runstate, both of continuously running threads...

I was referring to the topic title

"pthread: method to signalize if thread is running/exited?"

and the question I asked in the TOP:

is there a way to see from 1 pthread task (ID=pthread1, name=pthread1name ) if another pthread task (ID=pthread2, name=pthread2name) is running/sleeping/exited/halted/killed or what ever?s

this would be the first thing which has to be resolved, then comes the rest.

[Paeryn]

Killing a thread ( pthread_cancel(threadID)) is only intended in case of urgent emergency reasons after a certain latency when a safe stop failed.

Cancelling a thread isn't very good for "urgent emergency reasons" as if your thread is stuck in a loop it might not get to service the request (see below).

I'm still trying to figure out why you're insisting on wanting to query the system for the run state of a thread when you should already have all the information within your program. You know if you've started a thread, you know when a thread finishes (both natural finishing and cancelling)... It's not as though another process is going to be doing any of this without you knowing. As I said before, once a thread has finished (and you have called pthread_join() on it if it wasn't detached) then the thread id is no longer valid (unless another thread has been started and the system decides to re-use an old id, at which point it could be a thread that is doing something entirely different if you have multiple threads). So you can only make calls on active threads - i.e. you have to know already that it hasn't terminated (a joinable thread (the default) only terminates once it exits and has been joined, a detached thread terminates as soon as it exits).

All your threads share the same memory space (though they have separate local stacks) so they all have the ability to share their running state with each other. And since they are all part of the same process you should always know exactly which threads are running and what they are up to, no need to query the system.

Are you using pthread_cleanup_push() / pthread_cleanup_pop() in your thread to manage any needed clean up in cases of thread cancellation (if you need to)? Clean up functions on the cleanup stack will be called in reverse order whenever a cancellation is requested before the thread exits. Also have you made sure your threads have got cancellation points (function calls that are able to service pthread_cancel() requests)? If they get stuck in a loop without one then it could be ages (if ever) before they actually get cancelled so you can add a call to pthread_testcancel() in such a loop if you need it to be able to respond to a cancel request. man 7 pthreads should list all the functions calls that are cancellation points.

[davenull]

So you can only make calls on active threads

thanks, that was the missing information which I did not understand.
I thought that once having initialized at the start
pthread_t thread0, thread1, thread2, thread3, thread4, thread5;
then I faultily supposed all those IDs to be sort of fixed values and entities of whatever and all information about them could be polled somehow, either if running or sleeping or stopped intermediately.
Now I see my mistake.
Thanks for your explanation!

edit
and I see that there are lot of things I have to care of about tasks - I was sort of seduced by the convenience of having a VM doing all those magic things in the background....