26.02.2014 Views

Getting Started with QNX Neutrino - QNX Software Systems

Getting Started with QNX Neutrino - QNX Software Systems

Getting Started with QNX Neutrino - QNX Software Systems

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

© 2009, <strong>QNX</strong> <strong>Software</strong> <strong>Systems</strong> GmbH & Co. KG. More on synchronization<br />

it was told it could), it would use pthread_rwlock_rdlock(), and now it would block,<br />

because the resource was no longer available in that mode. So, if we didn’t lock it if<br />

we could, the thread that called the “try” version could still potentially block anyway!<br />

Finally, regardless of the way that the lock was used, we need some way of releasing<br />

the lock:<br />

int<br />

pthread_rwlock_unlock (pthread_rwlock_t *lock);<br />

Once a thread has done whatever operation it wanted to do on the resource, it would<br />

release the lock by calling pthread_rwlock_unlock(). If the lock is now available in a<br />

mode that corresponds to the mode requested by another waiting thread, then that<br />

thread would be made READY.<br />

Note that we can’t implement this form of synchronization <strong>with</strong> just a mutex. The<br />

mutex acts as a single-threading agent, which would be okay for the writing case<br />

(where you want only one thread to be using the resource at a time) but would fall flat<br />

in the reading case, because only one reader would be allowed. A semaphore couldn’t<br />

be used either, because there’s no way to distinguish the two modes of access — a<br />

semaphore would allow multiple readers, but if a writer were to acquire the<br />

semaphore, as far as the semaphore is concerned this would be no different from a<br />

reader acquiring it, and now you’d have the ugly situation of multiple readers and one<br />

or more writers!<br />

Sleepon locks<br />

Another common situation that occurs in multithreaded programs is the need for a<br />

thread to wait until “something happens.” This “something” could be anything! It<br />

could be the fact that data is now available from a device, or that a conveyor belt has<br />

now moved to the proper position, or that data has been committed to disk, or<br />

whatever. Another twist to throw in here is that several threads may need to wait for<br />

the given event.<br />

To accomplish this, we’d use either a condition variable (which we’ll see next) or the<br />

much simpler “sleepon” lock.<br />

To use sleepon locks, you actually need to perform several operations. Let’s look at<br />

the calls first, and then look at how you’d use the locks.<br />

int<br />

pthread_sleepon_lock (void);<br />

int<br />

pthread_sleepon_unlock (void);<br />

int<br />

pthread_sleepon_broadcast (void *addr);<br />

int<br />

pthread_sleepon_signal (void *addr);<br />

int<br />

pthread_sleepon_wait (void *addr);<br />

April 30, 2009 Chapter 1 • Processes and Threads 59

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!