The System Information perspective provides a complete and detailed report on your system's resource allocation and use, along with key metrics such as CPU usage, program layout, the interaction of different programs, and more:
The System Information perspective shows a detailed report of the system's resource allocation, CPU usage, and more.
The perspective's metrics may prove useful throughout your development cycle, from writing and debugging your code through your quality-control strategy.
Key terms
Before we describe how to work with the System Information perspective, let's first briefly discuss the terms used in the perspective itself. The main items are:
- 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
- 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 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 below).