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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

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

More on synchronization<br />

To sum up: know what the trade-offs are, and use what works for your design.<br />

We’ve already seen:<br />

• mutexes<br />

• semaphores<br />

• barriers<br />

Readers/writer locks<br />

Let’s now finish up our discussion of synchronization by talking about:<br />

• readers/writer locks<br />

• sleepon locks<br />

• condition variables<br />

• additional <strong>Neutrino</strong> services<br />

Readers and writer locks are used for exactly what their name implies: multiple<br />

readers can be using a resource, <strong>with</strong> no writers, or one writer can be using a resource<br />

<strong>with</strong> no other writers or readers.<br />

This situation occurs often enough to warrant a special kind of synchronization<br />

primitive devoted exclusively to that purpose.<br />

Often you’ll have a data structure that’s shared by a bunch of threads. Obviously, only<br />

one thread can be writing to the data structure at a time. If more than one thread was<br />

writing, then the threads could potentially overwrite each other’s data. To prevent this<br />

from happening, the writing thread would obtain the “rwlock” (the readers/writer lock)<br />

in an exclusive manner, meaning that it and only it has access to the data structure.<br />

Note that the exclusivity of the access is controlled strictly by voluntary means. It’s up<br />

to you, the system designer, to ensure that all threads that touch the data area<br />

synchronize by using the rwlocks.<br />

The opposite occurs <strong>with</strong> readers. Since reading a data area is a non-destructive<br />

operation, any number of threads can be reading the data (even if it’s the same piece of<br />

data that another thread is reading). An implicit point here is that no threads can be<br />

writing to the data area while any thread or threads are reading from it. Otherwise, the<br />

reading threads may be confused by reading a part of the data, getting preempted by a<br />

writing thread, and then, when the reading thread resumes, continue reading data, but<br />

from a newer “update” of the data. A data inconsistency would then result.<br />

Let’s look at the calls that you’d use <strong>with</strong> rwlocks.<br />

The first two calls are used to initialize the library’s internal storage areas for the<br />

rwlocks:<br />

April 30, 2009 Chapter 1 • Processes and Threads 57

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

Saved successfully!

Ooh no, something went wrong!