Should I use sleep or pthread_cond_wait?

George2 · 08-07-2005, 09:47 PM

Hello everyone,

If under some condition, the current thread needs to pause and let other thread to execute, should I use sleep + pthread_mutex_unlock or pthread_cond_wait? If both methods could be used, which one is more efficient?

Here is my example,

Code:

// solution using sleep + pthread_mutex_lock
while (1)
{
    pthread_mutex_lock (&mutex1);
    if (some condition)
    {
        pthread_mutex_unlock (&mutex1);
        sleep (3);
    }
    else
    {
        // execution
    }
}

Code:

// solution using pthread_cond_wait
while (1)
{
    pthread_mutex_lock (&mutex1);
    if (some condition)
    {
        pthread_cond_wait(&cond1, &mutex1);
    }
    else
    {
        // execution
    }
}

Could anyone help please? If both methods could be used, could anyone show me some samples to illustrate which one is more efficient?

thanks in advance,
George

paulsm4 · 08-07-2005, 10:18 PM

The "sleep" is bad; the "pthread_cond_wait()" can be vastly superior.

Why is "sleep" bad? Because you lose on two counts: you're doing unnecessary work by polling for the condition (depending on how frequently you poll, the performance hit could be *enormous*), and you're also introducing an unnecessary latency (what happens if the condition occurs the millisecond *after* you put yourself to sleep?), which could easily be perceived by users as poor performance.

One solution is to use the lock itself to prevent the thread from proceeding if the condition is untrue.

Another solution is to call pthread_cond_signal() in whatever active thread is causing the condition to be true.

Here's a link that might be helpful:
http://vergil.chemistry.gatech.edu/r...g/threads.html

George2 · 08-08-2005, 12:43 AM

Thanks paulsm4,

Quote:

Originally posted by paulsm4
The "sleep" is bad; the "pthread_cond_wait()" can be vastly superior.

Why is "sleep" bad? Because you lose on two counts: you're doing unnecessary work by polling for the condition (depending on how frequently you poll, the performance hit could be *enormous*), and you're also introducing an unnecessary latency (what happens if the condition occurs the millisecond *after* you put yourself to sleep?), which could easily be perceived by users as poor performance.

One solution is to use the lock itself to prevent the thread from proceeding if the condition is untrue.

Another solution is to call pthread_cond_signal() in whatever active thread is causing the condition to be true.

Here's a link that might be helpful:
http://vergil.chemistry.gatech.edu/r...g/threads.html

Your rely is very helpful. I understand the solution of using pthread_cond_signal(), but I do not quite understand the solution of using lock itself. As you mentioned, lock can prevent the thread from proceeding if the condition is untrue, but how can we wake it up to proceed when the condition is true? I can not imagine a method to do that other than using pthread_cond_signal().

regards,
George

paulsm4 · 08-08-2005, 11:19 AM

Hi -

Sorry I wasn't clearer. All I meant was:
1. Assume you have two threads, A and B
2. Thread B wants to wait until condition X == TRUE
3. Thread A happens to be the guy who sets X
4. Thread A could acquire the lock, and then release it after it sets X

*If* your design permitted this (a big "if"!), then you wouldn't need the signal at all.

PS:
If you were doing this under Windows, you'd use a Win32 "Event" instead of a Pthreads "signal".

George2 · 08-08-2005, 10:25 PM

Thanks paulsm4,

Quote:

Originally posted by paulsm4
Hi -

Sorry I wasn't clearer. All I meant was:
1. Assume you have two threads, A and B
2. Thread B wants to wait until condition X == TRUE
3. Thread A happens to be the guy who sets X
4. Thread A could acquire the lock, and then release it after it sets X

*If* your design permitted this (a big "if"!), then you wouldn't need the signal at all.

PS:
If you were doing this under Windows, you'd use a Win32 "Event" instead of a Pthreads "signal".

As you mentioned, thread B will wait until consition is true. I am wondering how could it wait other than using pthread_cond_wait? Suppose currently condition != TRUE, how could you ask thread B to wait?

PS: What do you mean "a big if"? Could you please show me an example about it?

regards,
George

paulsm4 · 08-08-2005, 11:50 PM

Hi -

I try to acquire a lock. If it's free, I get it, and everybody else who wants it has to wait until I free it.

What happens if it's *not* free?

Then *I* block. Until it's released. At which point I unblock and continue working.

Make sense?

I'm not sure how knowledgeable you are about threads and concurrency, and how much I'm telling you what you already know, and how much I'm *failing* to tell you pieces you *need* to know.

Strong suggestion: "Google" for a good tutorial on the web, or pick up this book:

Advanced Programming in the UNIX(R) Environment (2nd Edition)
W. Richard Stevens, Stephen A. Rago

George2 · 08-09-2005, 12:16 AM

Thanks paulsm4,

I agree with all of your statements and I understood them before. I am sorry that I do not make myself understood enough. My points are illustrated in the following.

Quote:

Originally posted by paulsm4
[B]Hi -

I try to acquire a lock. If it's free, I get it, and everybody else who wants it has to wait until I free it.

What happens if it's *not* free?

Then *I* block. Until it's released. At which point I unblock and continue working.

Make sense?

My meaning is that, in your previous sample (especially item 2),

Quote:

Originally posted by paulsm4
1. Assume you have two threads, A and B
2. Thread B wants to wait until condition X == TRUE
3. Thread A happens to be the guy who sets X
4. Thread A could acquire the lock, and then release it after it sets X

Suppose current condition is not X == TRUE, then in your description, thread B will wait. My meaning is that, how to program it, i.e. program "wait"? More precisely, I can not imagine a method that uses only pthread_lock and does not use any of pthread_cond_wait or sleep.

regards,
George

paulsm4 · 08-09-2005, 01:41 AM

Let me answer that question two ways:

1. One way to think of a "mutex" is something that you "lock"
when you enter a "critical section" (and, of course, that's what
the word "mutex" means: "mutual exclusion").

In this sense, your mutex is just a "binary semaphore": it's
either "locked" (entering the critical section) or "unlocked" (upon
having exited the critical section).

But semaphores are really far more general than that.
Supposing you *initialize* the semaphore to "locked". Then
"unlocking" it literally "signals" any or all threads that were
blocked waiting on it. And in fact, this is exactly how worker
threads in a thread pool are "notified" to wake up and service
incoming requests.

2. Second suggestion:

Please consider buying the Stevens book (or anything by
Tannenbaum that discusses concurrency: for example his
"Computer Networks" text).

Or please google for "semaphore", "monitor",
"Djikstra" and/or "dining philosphers".

I'm sorry I can't be more helpful, but I'm really afraid that I might
give you a misleadingly facile answer to what's really a fairly
deep subject.

Your .. PSM

George2 · 08-10-2005, 09:10 AM

Thanks paulsm4,

Your reply is very helpful! Previously, I think I do not quite understand the difference between lock and semaphore. Your reply makes me clear about it.

About the book, I am going to borrow it from library to save money.

Quote:

Originally posted by paulsm4
Let me answer that question two ways:

1. One way to think of a "mutex" is something that you "lock"
when you enter a "critical section" (and, of course, that's what
the word "mutex" means: "mutual exclusion").

In this sense, your mutex is just a "binary semaphore": it's
either "locked" (entering the critical section) or "unlocked" (upon
having exited the critical section).

But semaphores are really far more general than that.
Supposing you *initialize* the semaphore to "locked". Then
"unlocking" it literally "signals" any or all threads that were
blocked waiting on it. And in fact, this is exactly how worker
threads in a thread pool are "notified" to wake up and service
incoming requests.

2. Second suggestion:

Please consider buying the Stevens book (or anything by
Tannenbaum that discusses concurrency: for example his
"Computer Networks" text).

Or please google for "semaphore", "monitor",
"Djikstra" and/or "dining philosphers".

I'm sorry I can't be more helpful, but I'm really afraid that I might
give you a misleadingly facile answer to what's really a fairly
deep subject.

Your .. PSM

regards,
George