How Do i Resume thread in Linux

Hei gurs
Im new to linux. I have a multithreaded programs, in that I have used pause() system call which will pause that particular thread. How do i make the thread resume.

I have used pthread_create system call.

regards
balamurali c

You need to kill the thread !!

Well, more precisely you need to send it a signal via the kill (man 2 kill) system call.

You should have installed a signal handler for the signal that you are planning to use in the thread that you are pausing. (man 2 signal)

Use signals SIGUSR1 or SIGUSR2. They are reserved to be used by applications.

Quote:

---

Originally posted by treuss

Use signals SIGUSR1 or SIGUSR2. They are reserved to be used by applications.

---

No. These signals aren't helpful here.
If U go that way, U should "pause" thread in SIGUSR1 handler and "suspend" it in SIGUSR2.
It's a bad idea to be blocked in any signal handler.

I'm not sure about a new POSIX specification document, but there are no any functions for doing that now.

One way U can try for the old pthread realization is to send SIGSTOP to "pause" and SIGCONT to "suspend".
(_BUT_ it's not working for NPTL threads which is a new standard of linux threads. So forget about its using with 2.6.* kernels and even RH9.0 + its default NPTL)

ya thx for ur replies..

my actual problem is

viod MyThread(void *pParam)
{
while(1)
{
if(someCondition)
{
bPaused = TRUE
pause();
}
// Do some etc stuffs
...
...
...
}
}


int main()
{
iThreadID = pcraete_ create(....)
while(1)
{
// do some work again..
if(someCondition && bPaused)
Resume(iThreadID); /// How do I resume this thread again
}
}



this is my actual situation

How do I do it.

regards
balamurali c

treuss, U are right too.

I wrote 2 samples at yesterday's everning.
One of them shows your approach (SIGUSR1, SIGUSR2), another one shows mine (SIGSTOP, SIGCONT). Both of them are attached here (2 files: stop_cont.c and usr1_usr2.c are united in one file suspend_resume.txt).

BUT, those methods work because of NON POSIX compliant thread realization. Because each thread has its own process id (so U can use kill) and that sending a signal to the process as a whole is not implemented. All that (and some others) are drawbacks of the old pthread implementation. The recent one is NPTL. It have no that kind of drawbacks, so these methods donot work there.
I guess, that POSIX specification has to have some new methods provided to suspend/resume a thread using its thread ID.

U can read about NPTL (an article covers all drawbacks of the old pthread implementation too) here:
http://people.redhat.com/drepper/nptl-design.pdf

OK, I am really thinking more in terms of processes than threads. So, yes, kill will not work if you don't have a pid for the thread.

If I understand ccbalamurali right, he wants to only resume a thread from another thread/process. So only one signal handler is needed, not two.

As the signal is something that is intenal in the application (communication between parts of the program), I still believe one should use the private signal (SIGUSR1) as opposed to SIGCONT.

Use conditions instead (man pthread_cond_signal)

For example;

Code:

---

void MyThread(void *pParam)
{
  while(1)
  {
    if(someCondition)
    {
      pthread_cond_signal(m_conditionRaised);
      pthread_cond_wait(m_conditionSolved);
    }

    // Do some etc stuffs
    ...
    ...
    ...
  }
}


int main()
{
  // Launch MyThread...

  while(1)
  {
    pthread_cond_wait(m_conditionRaised);
    // do some work again...
    pthread_cond_signal(m_conditionSolved);
  }
}

---

Villemos

Sorry for the half finished reply before, now I finally found time to answer properly, see edited answer above...

Villemos.

Quote:

---

Originally posted by villemos
Use conditions instead (man pthread_cond_signal)

---

this is the ONLY general way actually - you can have some particular cases in which you know beforehand that only one thread will pause, set signal masks accordingly so that only that thread catches the signal you want to send. (afair the POSIX spec says that when several threads can catch a signal delivered to the app, the one to receive it will be chosen at random).

however, if you edited the code you could have corrected it too - you need a condition variable AND a mutex. also, for anything simple, only one condition variable should do fine.

dimm_coder,

You seem to know what is going on with Linux (NPTL and stuff). Do you know if there is any plan to support sem_open() in the future with Linux? Not being able to use named semaphores is a killer for some of the work I do.

Thanks!

- Kevin

Quote:

---

Originally posted by KevinHall
dimm_coder,

You seem to know what is going on with Linux (NPTL and stuff). Do you know if there is any plan to support sem_open() in the future with Linux? Not being able to use named semaphores is a killer for some of the work I do.

Thanks!

- Kevin

---

Yes. Follow the next link and search for the "sem_open" call:
http://people.redhat.com/~drepper/po...on-groups.html

U can find there:

Quote:

---

glibc 2.3 with NPTL has full support for semaphores, including named semaphores and inter-process semaphores. Earlier glibc versions have only support for anonymous semaphores.

---

That's the site of Ulrich Drepper. He is a current maintainer of glibc. So, I think, we can trust him :)

Thanks! I downloaded RedHat 9 when it first came out (advertised with NPTL) and it still didn't support named and inter-process semaphores. I'lll have to go figure out how get this now.