kill function in gcc

[yashkarandikar]

I was trying to use the kill function in gcc.. but the following code is not working the way it should...
thread1 gets stopped.
thread2 must get joined but it doesnt get joined and the program gets terminated.

// platform : red hat linux enterprise 5, gcc

#include <stdio.h>
#include <pthread.h>
#include <sys/types.h>
#include <signal.h>

void* prnt1 ()
{
int i;
for (i = 0; i < 100; ++i)
printf("10 ");

return NULL;
}

void* prnt2 ()
{
int i;
for (i = 0; i < 100; ++i)
printf("33 ");

return NULL;
}

int main () /* The main program. */
{
int i;
pthread_t thread1_id, thread2_id;

pthread_create (&thread1_id, NULL, &prnt1, NULL);
pthread_create (&thread2_id, NULL, &prnt2, NULL);

// send signal to thread1 to stop.
pthread_kill(thread1_id,SIGSTOP);
printf("\n Thread1 stopped.\n");

// join thread2 to complete its execution.
pthread_join (thread2_id, NULL);
printf("\n Thread2 completed.\n");

// send signal to thread1 to resume.
pthread_kill(thread1_id,SIGCONT);
printf("\n Thread1 resumed.\n");

pthread_join (thread1_id, NULL);
printf("\n Thread1 completed.\n");

return 0;
}

please let me know if u find anything wrong in the above code...

thanks

[wje_lf]

You can't get there from here.

The SIGSTOP signal is designed to work between processes. The process sending that signal doesn't need to know anything about what's going on inside the process receiving the signal. That's one nice thing about processes. (It's assumed that the sending process isn't going to be waiting on a file record lock that the stopped process is holding, but that's up to the programmer.)

Threads are more tightly bound together. If one thread were to be able to stop another thread regardless of what that thread was doing, there would be complications. Suppose, for example, that the thread being stopped was holding a mutex that the stopping thread was soon going to wait on. This would be chaotic.

When you design a program using POSIX threads, each thread needs to be at least minimally aware of what other threads in the process are doing, and it's usually best to use some pthreads mechanism to do so. For example, if thread fred is supposed to periodically suspend thread barney, a good way to do that would be to have a mutex which is locked by fred if it wants barney to suspend operations. Then barney, when it's safe and no undesired mutexes are being held, periodically locks and unlocks that mutex. If it's being held by fred, then barney will wait until fred releases it.

If, instead, you do

pthread_kill(thread1_id,SIGSTOP);

and it succeeds, then all threads in the process will be temporarily stopped until the process gets a SIGCONT. Suspending a single thread is not what SIGSTOP is for.

Five more important points.

1. Every call to pthread_something() returns an integer which is 0 if there was no error, and an integer from include file errno.h if there was an error.
   
   Check the return value from every call to a pthread function.
2. It is actually quite legal for your program to send the SIGSTOP signal to a thread, as long as you're willing to have all threads in that process stop. (But I know you're not willing).
3. I presume you know that in your sample program, it is quite possible for the sending of the STOP signal could be executed before anything in either thread1 or thread2 gets executed.
4. I presume you know that in your sample program, it is quite possible for both thread1 and thread2 to run to completion before the program sends the SIGSTOP signal.
5. The previous two points can be summarized thus:
   
   
   Don't make any assumptions about the relative order in which various threads run, unless you explicitly coordinate the threads by using mutexes.
   
   
   Making such assumptions, especially when you're not aware that you're making such assumptions, is probably the most common cause of pthreads programming bugs.

Hope this helps.

[tejas_patil]

i am satisfied with your answer but i am confused.

please go through this :-

implementation model for LinuxThreads:
---------------------------------------
LinuxThreads follows the so-called "one-to-one" model:
each thread is actually a separate process in the kernel.
The kernel scheduler takes care of scheduling the threads,
just like it schedules regular processes. The threads are
created with the Linux clone() system call, which is a
generalization of fork() allowing the new process to share
the memory space, file descriptors, and signal handlers of the parent.

(check out : LinuxThreads Frequently Asked Questions)

does this mean that threads arent actually implemented the way
we assume.

how to relate your answer to this ?

In my code, i dont want to use the inbuild
semaphore. i want to implement my own semaphore (personal wish).
is it possible ? if yes, how ?

[wje_lf]

does this mean that threads arent actually implemented the way we assume.

Most Linux users aren't using LinuxThreads any more. To see whether you're using LinuxThreads or NTPL (the newer, more accurate implementation of POSIX threads on Linux), do this at the command line:

getconf GNU_LIBPTHREAD_VERSION

i dont want to use the inbuild
semaphore. i want to implement my own semaphore (personal wish).
is it possible ?

Sure. How you do this depends on what tools you're willing to use. If you're willing to use advisory record locking, that's a good way to go. It's what I'd use. If you're not willing to do that, the best way may be to roll up your sleeves and start modifying the Linux kernel.

You may explore other alternatives, as well as reading up on semaphores in general, by going to Wikipedia.