views:

101

answers:

5

I want to suspend pthreads but apparently, there is no such function as pthread_suspend. I read somewhere about suspending pthreads using mutexes and conditions and used it as following:

#include <pthread.h>

class PThread {
public:
pthread_t myPthread;
pthread_mutex_t m_SuspendMutex;
pthread_cond_t m_ResumeCond;

void start() {
pthread_create(&myPthread, NULL, threadRun, (void*)this );
}

Thread() { }

void suspendMe() {
pthread_cond_wait(&m_ResumeCond,&m_SuspendMutex);
}

void resume() {
pthread_cond_signal(&m_ResumeCond);
}
};

but I don't understand why we need both mutex and condition to suspend and resume a pthread. Is it possible to suspend and resume it without using conditions?

+2  A: 

If a thread wasn't waiting on some condition or other, how could you "signal" it to resume. It can't just stop executing anything at all and then magically start again, so it waits on a condition.

To elaborate, in pthreads, the way to resume a thread is in fact to use condition variables. There isn't an API available to suspend/resume a thread in any other way. Waiting on pthread_cond_wait is cheap, it blocks until the condition is signaled, not using (much?) CPU. You use the condition to signal the thread to wake up, and the mutex is required to protect access to the condition variable and the code in the thread upon wakeup.

Mark B
+2  A: 

Your code is not correct - the pthread_cond_wait() requires that the mutex be locked already when you call it:

void suspendMe()
{
    pthread_mutex_lock(&m_SuspendMutex);
    pthread_cond_wait(&m_ResumeCond, &m_SuspendMutex);
    pthread_mutex_unlock(&m_SuspendMutex);
}

The reason the mutex is provided is to allow more complex code to avoid race conditions - the pthread_cond_wait() function actually performs an atomic-unlock-and-wait when it waits, which allows a "missed wakeup" to be avoided.

caf
Also, you are required to check your condition after wakeup because the system *may* wake your thread up with the condition false! For example, the system may have woken 10 threads and one of them already finished the job.
Zan Lynx
@Zan Lynx: Aye, POSIX is quite clear on this point: *"Spurious wakeups from the pthread_cond_timedwait() or pthread_cond_wait() functions may occur."* (although I believe the Linux implementation does not do spurious wakeups).
caf
+2  A: 

A condition is always associated with a mutex. Usually, a thread will sleep because it's waiting for a change of state to indicate that it has work to do; you need the mutex to guard access to that state, and the condition to signal the change.

Waking up a thread without telling it why you've woken it is a bit of an odd thing to do, so there's no special way to do it; the only way to do it is to use the normal mechanism, but with no shared state.

If for some reason you want to suspend and resume the thread from another thread, independently from giving it work to do, then you might be able to use pthread_kill to send it SIGSTOP and SIGCONT signals; I've never tried doing anything like that, so I've no idea whether or not it's supported.

Mike Seymour
A: 

Mutexes are used to ensure the exclusive access , where as condition variables are used to synchronize threads based on the events.

We need Mutexes to ensure that condition variables dont end up in an infinite wait. One thing to remember is Mutex operation of lock and unlock are guaranteed to be atomic, but the condition variables need not be. i.e The thread can get scheduled out while the condition variable wait is half way.

Consider the following case with out Mutex for condition variable.

Thread 1


1)Perform Some Operation
2)Wait on the Condition Variable
3)Continues the Operation

Thread 2


1) Perform some operation
2)Signal the Condition Variable
3)Continue the Operation

Here in the Thread 1 , the step 2 is not guaranteed to be atomic. If the Thread 1 is pushed out of RUNNING state by scheduler before it completes the step1. Now Thread 2 starts executing and signals the condition variable. When Thread 1 resumes execution it will finish the remaining low level instructions and starts waiting. Thread 1 ends up in an infinite wait, as the signal of condition variable occurred even before the wait.

So the Right way to use is (I believe the code mentioned in the question doesnt do the expected)

Thread 1 :-


1)Do work up to the point where a certain condition must occur (such as "count" must reach a specified value)
2)Lock associated mutex
3)Call pthread_cond_wait() to perform a blocking wait for signal from Thread1. ( Note that a call to pthread_cond_wait() automatically and atomically unlocks the associated mutex variable so that it can be used by Thread2)
4)When signalled, wake up. Mutex is automatically and atomically locked.
5)Explicitly unlock mutex

Thread2


1)Do work
2)Lock associated mutex
3)Change the value of the global variable that Thread1 is waiting upon.
4)Check value of the global Thread1 wait variable. If it fulfills the desired condition, signal Thread1.
5)Unlock mutex. Continue

pv
A: 

More to the point - what are you ultimately trying to do?? - I suspect the answer is not 'suspend a thread'. It may be that your program design has a problem.

jim mcnamara