Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG. More on synchronization
Pools of threads
and the process manager, which worries about memory protection and “processes”
(among other things). A mutex is really just a synchronization object used between
threads. Since the kernel worries only about threads, it really doesn’t care that the
threads are operating in different processes — this is an issue for the process manager.
So, if you’ve set up a shared memory area between two processes, and you’ve
initialized a mutex in that shared memory, there’s nothing stopping you from
synchronizing multiple threads in those two (or more!) processes via the mutex. The
same pthread_mutex_lock() and pthread_mutex_unlock() functions will still work.
Another thing that Neutrino has added is the concept of thread pools. You’ll often
notice in your programs that you want to be able to run a certain number of threads,
but you also want to be able to control the behavior of those threads within certain
limits. For example, in a server you may decide that initially just one thread should be
blocked, waiting for a message from a client. When that thread gets a message and is
off servicing a request, you may decide that it would be a good idea to create another
thread, so that it could be blocked waiting in case another request arrived. This second
thread would then be available to handle that request. And so on. After a while, when
the requests had been serviced, you would now have a large number of threads sitting
around, waiting for further requests. In order to conserve resources, you may decide to
kill off some of those “extra” threads.
This is in fact a common operation, and Neutrino provides a library to help with this.
We’ll see the thread pool functions again in the Resource Managers chapter.
It’s important for the discussions that follow to realize there are really two distinct
operations that threads (that are used in thread pools) perform:
• a blocking (waiting operation)
• a processing operation
The blocking operation doesn’t generally consume CPU. In a typical server, this is
where the thread is waiting for a message to arrive. Contrast that with the processing
operation, where the thread may or may not be consuming CPU (depending on how
the process is structured). In the thread pool functions that we’ll look at later, you’ll
see that we have the ability to control the number of threads in the blocking operation
as well as the number of threads that are in the processing operations.
Neutrino provides the following functions to deal with thread pools:
#include
thread_pool_t *
thread_pool_create (thread_pool_attr_t *attr,
unsigned flags);
int
thread_pool_destroy (thread_pool_t *pool);
int
April 30, 2009 Chapter 1 • Processes and Threads 69