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.

Scheduling and the real world<br />

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

per-thread setup required and for returning a context pointer (called ctp in the<br />

parameter lists). Note that the contents of the context pointer are entirely up to you —<br />

the library doesn’t care what you put into the context pointer.<br />

Now that the context has been created by context_alloc(), the block_func() function is<br />

called to perform the blocking operation. Note that the block_func() function gets<br />

passed the results of the context_alloc() function. Once the block_func() function<br />

unblocks, it returns a context pointer, which gets passed by the library to the<br />

handler_func(). The handler_func() is responsible for performing the “work” — for<br />

example, in a typical server, this is where the message from the client is processed.<br />

The handler_func() must return a zero for now — non-zero values are reserved for<br />

future expansion by QSS. The unblock_func() is also reserved at this time; just leave it<br />

as NULL. Perhaps this pseudo code sample will clear things up (it’s based on the same<br />

flow as shown in “Thread flow when using thread pools,” above):<br />

FOREVER DO<br />

IF (#threads < lo_water) THEN<br />

IF (#threads_total < maximum) THEN<br />

create new thread<br />

context = (*context_alloc) (handle);<br />

ENDIF<br />

ENDIF<br />

retval = (*block_func) (context);<br />

(*handler_func) (retval);<br />

IF (#threads > hi_water) THEN<br />

(*context_free) (context)<br />

kill thread<br />

ENDIF<br />

DONE<br />

Note that the above is greatly simplified; its only purpose is to show you the data flow<br />

of the ctp and handle parameters and to give some sense of the algorithms used to<br />

control the number of threads.<br />

Scheduling and the real world<br />

So far we’ve talked about scheduling algorithms and thread states, but we haven’t said<br />

much yet about why and when things are rescheduled. There’s a common<br />

misconception that rescheduling just “occurs,” <strong>with</strong>out any real causes. Actually, this<br />

is a useful abstraction during design! But it’s important to understand the conditions<br />

that cause rescheduling. Recall the diagram “Scheduling roadmap” (in the “The<br />

kernel’s role” section).<br />

Rescheduling occurs only because of:<br />

• a hardware interrupt<br />

• a kernel call<br />

• a fault<br />

76 Chapter 1 • Processes and Threads April 30, 2009

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

Saved successfully!

Ooh no, something went wrong!