A quick question about pthread_cond_wait()

Suppose multiple producers and consumers share a common queue.
Consumers are signaled when any producer puts data to the queue.

1. Does the following code has race condition?

Code:

//Producer:
pthread_mutex_lock(&lock);
//put data to a queue
pthread_cond_broadcast(&cond);
pthread_mutex_unlock(&lock);

Code:

//Consumer:
pthread_cond_wait(&cond, &lock);
//get data from the queue
pthread_mutex_unlock(&lock);

2. If I move the line pthread_cond_broadcast(&cond); out of mutex box as:

Code:

//Producer:
pthread_mutex_lock(&lock);
//put data to a queue
pthread_mutex_unlock(&lock);
pthread_cond_broadcast(&cond);

Does it has the same effect as the above code snippet?

I believe it does the same thing. The second seems better, since dunno for sure what will happen if you send a signal to a thread which is locked from some thread calling mutex_lock

Both are safe, but are you sure you want to wake all threads? Most likely the producer only added one item, right?

Edit: But I think the first one is better. It avoids spurious wakeups of consumers in one very rare situation.

With condition variable semantics, you need to have a predicate due to "spurious wakeups". If you have a predicate then calling signal/broadcast with the mutex locked or unlocked will both result in defined behavior.

You can read more on spurious wakeups at the bottom of the signal/broadcast documentation: http://www.opengroup.org/onlinepubs/...broadcast.html

You can read more on the implications of calling signal/broadcast with the mutex locked/unlocked here: http://groups.google.com/group/comp....e7ffb2f5264496

gg

Thanks all,
gg: Your links don't work?
CornedBee: I still don't understand why the first is better in terms of avoiding spurious wakeups. Would you elaborate more?

Hmm ... must have been a brain fart.