Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. More on synchronization
Okay, great. Now what about the “WAIT” call? As we suggested earlier, it’s
effectively the pthread_sleepon_wait() call. Here’s the second while loop:
while (!data_ready) {
pthread_sleepon_wait (&data_ready);
}
The pthread_sleepon_wait() actually does three distinct steps!
1 Unlock the sleepon library mutex.
2 Perform the waiting operation.
3 Re-lock the sleepon library mutex.
The reason it has to unlock and lock the sleepon library’s mutex is simple — since the
whole idea of the mutex is to ensure mutual exclusion to the data_ready variable, this
means that we want to lock out the producer from touching the data_ready variable
while we’re testing it. But, if we don’t do the unlock part of the operation, the
producer would never be able to set it to tell us that data is indeed available! The
re-lock operation is done purely as a convenience; this way the user of the
pthread_sleepon_wait() doesn’t have to worry about the state of the lock when it
wakes up.
Let’s switch over to the producer side and see how it uses the sleepon library. Here’s
the full implementation:
producer ()
{
while (1) {
// wait for interrupt from hardware here...
pthread_sleepon_lock ();
data_ready = 1;
pthread_sleepon_signal (&data_ready);
pthread_sleepon_unlock ();
}
}
As you can see, the producer locks the mutex as well so that it can have exclusive
access to the data_ready variable in order to set it.
It’s not the act of writing a 1 to data_ready that awakens the client! It’s the call to
pthread_sleepon_signal() that does it.
Let’s examine in detail what happens. We’ve identified the consumer and producer
states as:
April 30, 2009 Chapter 1 • Processes and Threads 61