I am trying to write a Teamcenter ITK program that will run as a different thread invoked from a main thread. The main thread is invoked from an action on the UI. Since the child thread takes a lot of time to complete, if I don't create the child thread and put the code in the main thread, the UI freezes for up to 10 minutes, which is not acceptable.
Both the main and child thread need to share authentication which was done by the main thread, since I am using SSO. They also need to connect to the database. Lastly, the main thread should not wait for the child thread to complete, since else the whole purpose of having the child thread will be defeated.
The code to invoke child thread is this:
handle = (HANDLE) _beginthread (submitToPublishTibcoWf, 0, &input); // create thread
do
{
sprintf(message, "Waiting %d time for 1000 milliseconds since threadReady is %d\n", i++, threadReady);
log_msg(message);
WaitForSingleObject(handle, 1000);
}
while (!threadReady);
sprintf(message, "Wait for thread to be ready over after %d tries since threadReady is %d\n", i, threadReady);
log_msg(message);
log_msg("Main thread about to exit now");
I set the threadReady = 1 global variable whenever I am about to execute the piece of code in the child thread that takes 8 minutes to run.
The problem is that the child thread is behaving weirdly after the main thread has exited, and I get this error:
Fri May 25 11:34:46 2012 : Main thread about to exit now
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Most of the child thread executes but sometimes it just crashes towards the very end.
To prevent exiting of the child thread, we can use detaching to make child process independent and not expected to join to parent.
Thus we should not join child process and after that, we have to detach from main thread:
pthread_create(th, attr, what);
pthread_detach(th);
// and never join
Also:
If you want to add some efficiency to your application, I suggest not to use exhaustive listening of observing special event of signal like threadReady. Instead use condition variables in pthread or another signaling methods like gObject.
You have some data shared between threads and it can face mutual exclusion problem and other problems such these in multi-processing or multi-threading applications can take place in. Instead try to handle this by hand of use some mechanisms like mutex or semaphore of condition variables.
Related
So lets say you create a thread in main (thread 1). This thread takes in some input from a file and creates multiple other threads (thread 2...etc) to process something. Do you have to exit the other threads (thread 2...) before exiting thread 1? If so how would I go about waiting for all the threads spawned by thread 1 to finish?
There are no parent/child relationships among threads. Threads are all peers. It makes no difference which thread started another thread, all the threads are equal parts of the process that contains them.
The special rule about calling pthread_exit from main only applies because returning from main terminates the process. There is no such concern with other threads -- they could only terminate the process by calling exit or a similar function.
Note that you should either join or detach each thread. You can detach all your threads and then you never have to worry about joining them -- they'll just run to completion and then clean themselves up.
No, you don't have to wait for the other threads to exit, in most situations. The whole point of threads is to start a sub-process of sorts that's largely independent of the thread that started it.
If you don't care how/when the thread will exit, though, you should usually detach the thread. Otherwise, it'll assume you care about its exit status, and it will sit there taking up resources -- even after it exits -- until some other thread joins it to retrieve the exit status.
I create more than 100 threads from my main() so I just wanted to know that do I need to call pthread_join() before I exit my main().
Also, I do not need the data generated by these threads, basically, all the threads are doing some job independent from main() and other threads.
pthread_join does two things:
Wait for the thread to finish.
Clean up any resources associated with the thread.
If you exit the process without joining, then (2) will be done for you by the OS (although it won't do thread cancellation cleanup, just nuke the thread from orbit), and (1) will not. So whether you need to call pthread_join depends whether you need (1) to happen.
If you don't need the thread to run, then as everyone else is saying you may as well detach it. A detached thread cannot be joined (so you can't wait on its completion), but its resources are freed automatically if it does complete.
Yes if thread is attachable then pthread_join is must otherwise it creates a Zombie thread.
Agree with answers above, just sharing a note from man page of pthread_join.
NOTES
After a successful call to pthread_join(), the caller is guaranteed that the target thread has terminated.
Joining with a thread that has previously been joined results in undefined behavior.
Failure to join with a thread that is joinable (i.e., one that is not detached), produces a "zombie thread". Avoid doing this, since each zombie thread consumes some system resources, and when
enough zombie threads have accumulated, it will no longer be possible to create new threads (or processes).
When you exit, you do not need to join because all other threads and resources will be automatically cleaned up. This assumes that you actually want all the threads to be killed when main exits.
If you don't need to join with a thread, you can create it as a "detached" thread by using pthread_attr_setdetachstate on the attributes before creating the thread. Detached threads cannot be joined, but they don't need to be joined either.
So,
If you want all threads to complete before the program finishes, joining from the main thread makes this work.
As an alternative, you can create the threads as detached, and return from main after all threads exit, coordinating using a semaphore or mutex+condition variable.
If you don't need all threads to complete, simply return from main. All other threads will be destroyed. You may also create the threads as detached threads, which may reduce resource consumption.
By default threads in pthreads library are created as joinable.
Threads may, however, detach, rendering them no longer joinable. Because threads consume system resources until joined, just as processes consume resources until their parent calls wait(), threads that you do not intend to join must be detached, which is a good programming practice.
Of course once the main routine exits, all threading resources are freed.
If we fail to do that(detaching), then, when the thread terminates it produces the thread equivalent of a zombie process. Aside from wasting system resources, if enough thread zombies accumulate, we won't be able to create additional threads.
Per default a thread runs attached, that means the resources it needs are kept in use until the thread is joined.
As from your description noone but the thread itself needs the thread's resources, so you might create the thread detached or detach the thread prior to having it started.
To detach a thread after its creation call pthread_detach().
Anyhow if you want to make sure all threads are gone before the program ends, you should run the threads attached and join them before leaving the main thread (the program).
If you want to be sure that your thread have actually finished, you want to call pthread_join.
If you don't, then terminating your program will terminate all the unfinished thread abruptly.
That said, your main can wait a sufficiently long time until it exits. But then, how can you be sure that it is suffucient?
If your main ends your application ends and your threads die... So you do need to use thread join (or use fork instead).
I am sorry for the basicness of this question, but I am having an issue here. I have a client-server program. I don't know before hand how many connections will come but they are not infinite. And at the end , after all connections are closed some results are output. But the problem I am having is, accepting connections is in an infinite while loop, how is it stoppedd to output the result.
Thanks
you need to have some form of condition to break out of you loop, in your case, a timeout would probably work the best, basically meaning, if you don't get any new clients for x seconds, you stop looking for clients, same goes for any for of connection error.
Anything more requires looking at the code you are using.
Handling EINTR on error from accept(2) with terminating the program and hitting ^C usually works.
You could install a handler for the SIGTERM signal which would set a global volatile sig_atomic_t variable, and test that variable in your multiplexing loop (probably around poll or select). Remember that signal handlers cannot call many functions (only the async-signal-safe ones).
Catching nicely SIGTERM is expected from most Linux or Posix servers.
You could consider using an event handling library like libev, libevent etc.
Although my background is with Windows NT the function "names" are ones that name generic threading or process functions that should be available in any multi-threading environment.
If the main thread can determine when the child thread in question should terminate it can either do this by having the child thread loop on a boolean - such as "terminate_conditon" - or by terminating the thread throught its handle.
// child thread
terminate_condition=FALSE;
while (!terminate_condition)
{
// accept connections
}
child_thread_done=TRUE;
// output results
exit_thread ();
// main thread
child_thread_done=FALSE;
child_thread=create_thread (...);
// monitor connections to determine when done
terminate_condition=TRUE;
while (!child_thread_done)
{
sleep (1);
}
// or maybe output results here?
exit_process ();
This controlled termination solution requires that only one thread writes to the child_thread_done boolean and that any other thread only reads.
Or
// child thread
while (1)
{
// accept connections
}
// main thread
child_thread=create_thread (...);
// monitor connections to determine when done
kill_thread (child_thread);
// output results
exit_process ();
The second form is messier since it simply kills the child thread. In general it is better to have the child thread perform a controlled termination, especially if it has allocated resources (which become the responsibility of the process as a whole rather than just the allocating thread).
If there are many child threads working with connections a synchronized termination mechanism is necessary: either a struct with as many members as there are child threads (a terminating thread sets its "terminated" boolean to true, terminates and the main thread monitors the struct to make sure all child "terminated" booleans are true before proceeding) or a counter containing the number of child threads operating (when a child is about to terminate it takes exclusive control of the counter via a spinlock, decrements it and frees the lock before terminating: the main thread doesn't do anything before the counter contains zero).
I've been using the pthread library for creating & joining threads in C.
When should I create a thread as detached, right from the outset? Does it offer any performance advantage vs. a joinable thread?
Is it legal to not do a pthread_join() on a joinable (by default) thread? Or should such a thread always use the detach() function before pthread_exit()ing?
Create a detached thread when you know you won't want to wait for it with pthread_join(). The only performance benefit is that when a detached thread terminates, its resources can be released immediately instead of having to wait for the thread to be joined before the resources can be released.
It is 'legal' not to join a joinable thread; but it is not usually advisable because (as previously noted) the resources won't be released until the thread is joined, so they'll remain tied up indefinitely (until the program exits) if you don't join it.
When should I create a thread as detached, right from the outset?
Whenever the application doesn't care when that thread completes and doesn't care about its return value of a thread, either (a thread may communicate a value back to other thread/application via pthread_exit).
For example, in a client-server application model, a server may create a new thread to process each request. But the server itself doesn't care about thread's return value of the thread. In that case, it makes sense to created detached threads.
The only thing the server needs to ensure is that the currently processed requests are completed. Which it can do so, just by exiting the main thread without exiting the whole program/application. When the last thread in the process exits, the application/program will naturally exit.
The pseudocode might look like:
/* A server application */
void process(void *arg)
{
/* Detach self. */
pthread_detach(pthread_self());
/* process a client request. */
pthread_exit(NULL);
}
int main(void)
{
while (not_done) {
pthread_t t_id;
errno = pthread_create(&t_id, NULL, process, NULL);
if (errno) perror("pthread_create:");
}
/* There may be pending requests at this point. */
/* Just exit the main thread - not the whole program - so that remaining
requests that may still be processed can continue. */
pthread_exit(NULL);
}
Another example could be a daemon or logger thread that logs some information at regular intervals for as long as the application runs.
Does it offer any performance advantage vs. a joinable thread?
Performance-wise, there's no difference between joinable threads vs detached threads. The only difference is that with detached threads, its resources (such as thread stack and any associated heap memory, and so on - exactly what constitutes those "resources" are implementation-specific).
Is it legal to not do a pthread_join() on a joinable (by default) thread?
Yes, it's legal to not join with a thread. pthread_join is a just convenience function that's by no means needs to be used unless you need. But note that the threads created are joinable threads by default.
An example when you might want to join is when threads do a "piece" of work that's split between them. In that case, you'd want to check all threads complete before proceeding. Task farm parallelism is a good example.
Or should such a thread always use the detach() function before pthread_exit()ing?
Not necessary. But you'd often want to decide whether you want a joinable or detached thread at the time of creation.
Note that while a detachable thread can be created in by setting the attribute PTHREAD_CREATE_DETACHED with a call to pthread_attr_setdetachstate, a thread decide can decide to detach itself at any point in time e.g. with pthread_detach(pthread_self()). Also, a thread that has the thread id (pthread_t) of another thread can detach with pthread_detach(thread_id);.
I use pthread_create to create several child threads. At a time, the main thread wants to kill all child threads or there will be segment falut. Which function should I use to finish that? I searched the answer from google and got function like pthread_kill. But I did not know which signal should I send to the child thread to kill them. My running environment is RHEL 5.4 and programming language is C.
In general, you don't really want to violently kill a child thread, but instead you want to ask it to terminate. That way you can be sure that the child is quitting at a safe spot and all its resources are cleaned up.
I generally do this with a small piece of shared state between parent and child to allow the parent to communicate a "quit request" to each child. This can just be a boolean value for each child, protected by a mutex. The child checks this value periodically (every loop iteration, or whatever convenient checkpoints you have in your child thread). Upon seeing "quit_request" being true, the child thread cleans up and calls pthread_exit.
On the parent side, the "kill_child" routine looks something like this:
acquire shared mutex
set quit_request to true
pthread_join the child
The pthread_join may take some time, depending on how frequently the child checks its quit request. Make sure your design can handle whatever the delay may be.
It is possible to "cancel" a thread using pthread_cancel. However, this isn't typically best practice though under extreme circumstances like a SEGFAULT it may be conisdered a reasonable approach.
You should send SIG_TERM to each of your threads, using
int pthread_kill(pthread_t thread, int sig);
A quick way to get rid of all threads (besides the main) is to fork() and keep going with the child.
Not hyper clean...
if (fork()) exit(0); // deals also with -1...
You can use a global variable for the entire program.
int _fCloseThreads;
Set it to 1 when you want the threads to quit execution. Have the threads check that variable in their "loop" and nicely quit when it is set to 1. No need to protect it with a mutex.
You need to wait for the threads to quit. You can use join. Another way is to increment a counter when a thread enters its thread proc and then decriment the counter when it exits. The counter would need to be a global of sorts. Use gcc atomic ops on the counter. The main thread, after setting fCloseThreads, can wait on the counter to go to zero by looping, sleeping, and checking the count.
Finally, you might checkout pthread_cleanup_push and pop. They are a model for allowing a thread to cancel anywhere in its code (uses a longjump) and then call a final cleanup function before exiting threadproc. You basicly put cleanup_push at the top of your threadproc and cleanup_pop at the bottom, create an unwind function, and then at certain cancelation points a thread canceled by a call to pthread_cancel() will longjump back to threadproc and call the unwind function.