How can I see the number of threads placed in a process in C ?
Actually, What I find out is whether newly-created process has one thread or no thread.(I am working in Linux)
The pthread_create() function starts a new thread in the calling process.So technically yes you can say there are two threads.The main thread,however remains the dominating one ,returning from main() causes the termination of all threads in the process.
Related
I have to code a C program that runs several processes.
If one of these processes stops, I need them all other processes to exit properly (free everything + close every opened semaphores).
Processes can stop either because an error occured or because they died (a specific condition related to my program's purpose).
I only can use semaphores (no mutexes) and the pthread_create, pthread_join, ptthread_detach functions, no signals allowed !
What I did: I run 3 threads per process:
1 thread to execute the main purpose of my process (M),
1 thread to check for any other process' death (D),
1 thread to check for any other process' error (E),
Thread M just runs by default.
For threads D and E, I have a semaphore named /death (or /error) that is worth 0 when initialized. Whenever a process dies (or encounters an error), it posts this semaphore so it will enter in the respective thread, free everything, then posts it again to allow any other process to free again and quit and etc...
Here is an example for the death thread:
void *D_thread(void *args)
{
sem_wait(death_sem);
frees_everything();
sem_post(death_sem);
exit(0);
}
I have 2 issues:
While entering the D thread for example, my process will start freeing all its resources, while its M thread is still running and trying to access to these resources. Could this be a source of errors and should I then protect this with another semaphore ?
My processes will free one after the other, resulting potentially in a slow exit if many processes run together.
Do you think this is a good method or can you think of something else more efficient ? Again: I only can use semaphores (no mutexes) and the pthread_create, pthread_join, pthread_detach functions, no signals allowed !
Is there a way to close all created threads if I don't have a list of their identifiers?
It is assumed that I only need the main thread, and the rest can be closed.
It's usually a good idea to have threads in charge of their own lifetime, periodically checking for some event indicating they should shut down. This usually make the architecture of your code much easier to understand.
What I'm talking about is along the lines of (pseudo-code):
def main():
# Start up all threads.
synchronised runFlag = true
for count = 1 to 10:
start thread threadFn, receiving id[count]
sleep for a bit
# Tell them all to exit, then wait.
synchronised runFlag = false
for count = 1 to 10:
wait for thread id[count] to exit
exit program
def threadFn():
initialise
# Thread will do its stuff until told to stop.
while synchronised runFlag:
do something relatively quick
exit thread
The periodic checking is a balance between efficiency of the thread loop and the amount of time you may have to wait for the thread to exit.
And, yes, I'm aware that pseudo-code uses identifiers (that you specifically stated you didn't have), but that's just one example of how to effect shutdown. You could equally, for example:
maintain a (synchronised) thread count incremented as a thread starts and decremented when it stops, then wait for it to reach zero;
have threads continue to run while a synchronised counter hasn't changed from the value it was when the thread started (you could just increment the counter in main then freely create a new batch of threads, knowing that the old ones would eventually disappear since the counter is different).
do one of a half dozen other things, depending on your needs :-)
This "lifetime handled by thread" approach is often the simplest way to achieve things since the thread is fully in control of when things happen to it. The one thing you don't want is a thread being violently killed from outside while it holds a resource lock of some sort.
Some threading implementations have ways to handle that with, for example, cancellability points, so you can cancel a thread from outside and it will die at such time it allows itself to. But, in my experience, that just complicates things.
In any case, pthread_cancel requires a thread ID so is unsuitable based on your requirements.
Is there a way to close all created threads if I don't have a list of their identifiers?
No, with POSIX threads there is not.
It is assumed that I only need the main thread, and the rest can be closed.
What you could do is have main() call fork() and let the calling main() (the parent) return, which will end the parent process along with all its thread.
The fork()ed off child process would live on as a copy of the original parent process' main() but without any other threads.
If going this route be aware, that the threads of the process going down might very well run into undefined behaviour, so that strange things might happen including messy left-overs.
All in all a bad approach.
Is there a way to close all created threads if I don't have a list of their identifiers? It is assumed that I only need the main thread, and the rest can be closed.
Technically, you can fork your process and terminate the parent. Only the thread calling fork exists in the new child process. However, the mutexes locked by other threads remain locked and this is why forking a multi-threaded process without immediately calling exec may be unwise.
I am wondering, what can happen if we do a pthread_create without a pthread_join?
Who will "clean" all the memory of the "non-joined" thread.
When the process terminates, all resources associated with the process cease to exist. (This of course does not include shared resources the process created, like files in the filesystem, shared memory segments, etc.) Until then, unjoined threads will continue to consume resources, potentially calling future calls to pthread_create or even malloc to fail.
Well, assuming that it's an app-lifetime thread that does not need or try to explicitly terminate, the OS will do it when its process is terminated, (on all non-trivial OS).
If the thread is created without using pthread_join then when the main thread completes execution all other threads created in main function will be stopped and hence will not complete executing the whole statements in it.
Look at the documentation of Pthread_join.
It will make the main thread to suspend until the spawned thread completes execution.
If I called pthread_create() to create a thread, how can I make this thread stay alive even if the main process has exited?
If you detach the thread, the process will not actually end until the last detached thread has finished, however only the detached threads will run.
You can detach a thread using pthread_detach.
For this to work though, you have to exit the main thread (the one running the main function) using pthread_exit and not exit or by returning from it.
It is not possible. Process consists of threads and thread cannot exist by itself.
However, if you meant 'main thread has exited' instead of 'main process has exited', then see the last explanation below in case where main() exits without calling pthread_exit. In this case all the threads are terminated implicitly. If main() called pthread_exit before termination, then only the main thread exits and the other created threads continue to run.
There are several ways in which a thread may be terminated:
The thread returns normally from its starting routine. It's work is done.
The thread makes a call to the pthread_exit subroutine - whether its work is done or not.
The thread is canceled by another thread via the pthread_cancel routine.
The entire process is terminated due to making a call to either the exec() or exit()
If main() finishes first, without calling pthread_exit explicitly itself
It is not possible to have an alive thread after main process has exited. However using pthread_exit(..) instead of exit(..) inside main(..), you can wait for other threads to exit. This will terminate the main thread but other threads will continue to execute.
For more information about pthread_exit(), visit this link.
It is not possible to make thread stay alive even if the main process has exited.
As thread are part of main process and it uses the same resource, once main program got exited
it will also free its resources. So thread can not be alive after process exit.
A thread runs "under" a process. The main() code runs in a thread. Any other threads that you create in main() (or in other threads) run under the same process.
It should be possible to let your main() thread exit WITHOUT waiting to join other threads that are currently running under the same process. However, I mostly use Windows and have NOT tried this running in a *nix system.
If you do this make sure each thread releases its resources prior to exiting.
What you can do is to not exit main(). At the end of your processing in main, right where you would otherwise exit, just put in something like:
int main(void) {
...
...
while (1) sleep(10);
return (0);
}
... or something similar. A process is a container for all the threads spawned within it, and it must exist for the threads to continue to exist. There is no harm in leaving the main() thread alive so that other threads continue to execute.
A thread on itself cannot be made running outside its generating main thread.
It's the definition of thread.
Now, what you can do is to have that thread spawn another process with all the relevant information and then joining back to the main thread before dying.
Anything else I fear will require the main thread to be kept alive.
I have three questions which are causing me a lot of doubts:
If one thread in a program calls fork(), does the new process
duplicate all threads, or is the new process single-threaded?
If a thread invokes exec(), will the program specified in the parameter
to exec() replace the entire process including ALL the threads?
Are system calls preemptive? For example whether a process can be scheduled in middle of a system call?
For exec, from man execve:
All threads other than the calling thread are destroyed during an execve().
From man fork:
The child process is created with a single thread — the one that called fork().
W.r.t. #3: Yes, you can invoke a system call that directly or indirectly makes another thread ready to run. And if that thread has a greater priority than the current and the system is designed to schedule it right then, it can do so.