The QNX System Information perspective provides a complete report on your target system's state,
including key details such as CPU usage, program layout, process and thread interaction, and more:
The perspective's metrics may prove useful throughout your development cycle, from writing and debugging code to system-wide quality assurance.
Key terms
- thread
- The minimum unit of execution that can be scheduled to run.
- process
- A container for threads, defining the virtual address space within which threads
execute. A process always contains at least one thread. Each process has its own
set of virtual addresses, typically ranging from 0 to 4
GB.
Threads within a process share the same virtual memory space, but have their own stack. This common address space lets threads within the process easily access shared code and data, and lets you optimize or group common functionality, while still providing process-level protection from the rest of the system.
- scheduling priority
- QNX Neutrino uses priorities to establish the order in which
threads get to execute when multiple threads are competing for CPU
time.
Each thread can have a scheduling priority ranging from 1 to 255 (the highest priority), independent of the scheduling policy. The special idle thread (in the process manager) has priority 0 and is always ready to run. A thread inherits the priority of its parent thread by default.
You can set a thread's priority using the pthread_setschedparam function.
- scheduling policy
- When two or more threads share the same priority (i.e. the threads are
directly competing with each other for the CPU), the OS relies on the threads'
scheduling policy to determine which thread should run next. Three policies are
available:
- round-robin
- FIFO
- sporadic
You can set a thread's scheduling policy using the pthread_setschedparam function or you can start a process with a specific priority and policy by using the on command (see the Utilities Reference for details).
- state
- Only one thread can actually run at any one time. If a thread isn't in this RUNNING state, it must either be READY or BLOCKED (or in one of the many blocked variants).
- message passing
- The most fundamental form of communication in QNX Neutrino. The OS relays messages from thread to thread via a send-receive-reply protocol. For example, if a thread calls MsgSend, but the server hasn't yet received the message, the thread would be SEND-blocked; a thread waiting for an answer is REPLY-blocked, and so on.
- channel
- Message passing is directed towards channels and connections, rather than targeted directly from thread to thread. A thread that wishes to receive messages first creates a channel; another thread that wishes to send a message to that thread must first make a connection by attaching to that channel.
- signal
- Asynchronous event notifications that can be sent to your process. Signals may
include:
- simple alarms based on a previously set timer
- a notification of unauthorized access of memory or hardware
- a request for termination
- user-definable alerts
The OS supports the standard POSIX signals (as in UNIX) as well as the POSIX realtime signals. The POSIX signals interface specifies how signals target a particular process, not a specific thread. To ensure that signals go to a thread that can handle specific signals, many applications mask most signals from all but one thread.
You can specify the action associated with a signal by using the sigaction function, and block signals by using sigprocmask. You can send signals by using the raise function, or send them manually using the Target Navigator view (see "Sending a signal").