Smartphone Operating System (779883), страница 18
Текст из файла (страница 18)
When PIDs reach 32 768, the system starts thenumbering process over and finds an unused PID starting at 0.In Linux, processes not only record parents and children, but alsosiblings. Relationships much like those shown in Figure 4.5 exist. Siblingrelationships make it much easier to pass around notification of events,such as interrupts and termination events.Processes in various states in Linux are grouped together in queues.The ready queue holds the processes in the ready state that are waitingto be executed.
There are also wait queues that hold the processes inthe waiting and uninterruptible states. Processes in the zombie state donot need a queue, since there is no order to their movement out of thezombie state. Wait queues are split into subclasses of processes basedon the event for which they are waiting. Those waiting for disk I/O, forexample, are put together in their own queue separate from processeswaiting for keyboard I/O.ParentChildntre dP a h ilCP1PaC renhi tldP0SiblingP2SiblingP3ParentChildP4Figure 4.5 Process relationships in Linux76PROCESSES AND THREADSContext-switching in Linux often uses hardware to make the switchingfaster. Since Linux has been focused on the Intel hardware architecture, it takes advantage of hardware context-switching to automatically save contexts.
However, using hardware to do this means thatthe operating system cannot ensure the validity of the process data.In addition, Linux has branched out from its Intel beginnings intoother hardware. For these reasons, software context-switching usingkernel-mode procedures is implemented in the most recent versions ofLinux.One final note should be made about the process hierarchy. Everyfamily tree has a root and the Linux process hierarchy has a processwith ID 0. This process is a process started by the boot sequenceand it has the duty of initializing all operating system tables andof starting process 1, or the ‘init’ process.
The init process has thejob of starting all other processes that are needed to run a Linuxsystem.Threads in Linux follow a standard called Pthreads. Support forPthreads follows the portable operating system interface (POSIX) standardand defines an API for thread creation and synchronization. This standardaccompanies an older standard also supported by Linux. POSIX is aset of standard APIs for system calls and was invented as a wayto smooth out the differences between Unix implementations.
Mostversions of Unix and Linux adhere to the POSIX standards, as domany other operating systems. Since support is voluntary, many operating systems – including Microsoft Windows and Symbian OS – providesupport for POSIX in selected areas of API definition. POSIX is supported by the Open Group (for more information, see their web site atwww.opengroup.org).Processes, Threads and Active Objects in Symbian OSSymbian OS favors threads and is built around the thread concept.
Aprocess is seen by the operating system as a collection of threads with aPCB and memory space. Thread support in Symbian OS is based in thenanokernel with nanothreads.Recall that the nanokernel is the basic, lowest level of the kernel.It provides very simple thread support in the form of nanothreads. Thenanokernel provides for nanothread-scheduling, synchronization (communication between threads) and timing services. Nanothreads run inprivileged mode and need a stack to store their run-time-environmentAN OVERVIEW OF THE PROCESS MODEL77data. Nanothreads do not run in user mode; this fact means that theoperating system can keep tight control over each thread. Each threadneeds a very minimal set of data to run, basically the location of itsstack and how big that stack is.
The operating system keeps control ofeverything else, for example, the code each thread uses, and stores athread’s context on its run-time stack.Nanothreads have thread states in the same way as processes havestates. The model used by the Symbian OS nanokernel adds a few states tothe basic model in Figure 4.1. In addition to the basic states, nanothreadscan be in the following states:• suspended : different from the waiting state – a thread is blocked bysome upper layer object (e.g., a Symbian OS thread)• fast Semaphore Wait : waiting for a fast semaphore – a type of sentinelvariable – to be signaled (see Chapter 6)• DFC Wait : waiting for a delayed function call (DFC) to be added tothe DFC queue; DFCs implement an interrupt service in Symbian OS,allowing a function call to be processed after the interrupt is serviced• sleeping : waiting for a specific amount of time to elapse• other : a generic state that is used when developers implement extrastates for nanothreads, to extend the nanokernel functionality fornew platforms (called personality layers); the developer must alsoimplement how states are transitioned to and from their extendedimplementations.Compare the nanothread idea with the conventional idea of a process.
A nanothread is essentially an ultra-lightweight process. It hasa mini-context that gets switched as nanothreads get moved into andout of the processor. Each nanothread has a state, as do processes.The keys to nanothreads are the tight control that the nanokernelhas over them and the minimal data that make up the context ofeach one.Symbian OS threads build upon nanothreads; the kernel adds support beyond what the nanokernel provides. User-mode threads thatfeature in standard applications are implemented by Symbian OS threads.Each Symbian OS thread contains a nanothread and adds its own runtime stack to the stack the nanothread uses. Symbian OS threads can78PROCESSES AND THREADSoperate in kernel mode via system calls.
Symbian OS also adds exception handling and exit signaling to the implementation of Symbian OSthreads.Symbian OS threads implement their own set of states on top of thenanothread implementation to reflect the new ideas built into SymbianOS threads. Symbian OS adds seven new states for threads, focused onspecial blocking conditions that can happen to a Symbian OS thread.These special states include waiting and suspending on semaphores,mutex variables and condition variables (see Chapter 6). Rememberthat, because of the implementation of Symbian OS threads on top ofnanothreads, these states are implemented in terms of nanothread states,mostly by using the suspended state in various ways.Processes, then, are Symbian OS threads grouped together under asingle PCB structure with a single memory space.
There may be onlya single thread of execution or there may be many threads under onePCB. Concepts of process state and process scheduling have already beendefined by Symbian OS threads and nanothreads. Scheduling a process,then, is really implemented by scheduling a thread and choosing the rightPCB to use for its data needs.Symbian OS threads organized under a single process are connectedin several ways:• a main thread is marked as the starting point for the process• threads share scheduling parameters; changing parameters for theprocess changes the parameters for all threads• threads share memory-space objects, including device and otherobject descriptors• when a process is terminated, the kernel terminates all threads in theprocess.Active objects are specialized forms of threads and are implementedin a special way to lighten their burden on the operating environment.Remember that active objects are organized so that when they arebrought back from a blocked state, they have a specific entry point intotheir code that is called.
Since they run in user space, active objects areSymbian OS threads. As Symbian OS threads, active objects have theirown nanothreads and can join with other Symbian OS threads to form aprocess to the operating system.PROGRAMMING WITH PROCESSES79As active objects are Symbian OS threads, one can ask what theadvantage is of using them. The key to active objects is in scheduling,which we cover in Chapter 5.
It is important to realize, however, whereactive objects fit into the Symbian OS process structure. When a threadmakes a system call that blocks its execution while in the waiting state,the operating system still needs to check the thread. The operating systemspends time between context switches checking waiting processes todetermine if they need to move to the ready state. Active objects wait fora specific event. The operating system does not need to check them butmoves them when their specific event occurs. The result is less threadchecking and faster performance.4.2 Programming with ProcessesHow we think about processes affects how we program those processes.
Akey element, then, to understanding how processes work is to understandhow they are programmed. This means studying the system calls andthe programming patterns that are used when processes and threads aremanipulated.There are several types of programming methods for processes. Anolder, more traditional way focuses on processes. Another method incorporates threads into this conventional programming model.
A third wayof programming uses specialized thread objects such as Symbian OSactive objects. These are all illustrated in this section.The Conventional ModelThe conventional model works at the process level. Processes are createdby an operation called a fork, which creates a new process by buildinga new PCB and placing the new process in the ready queue. The forkoperation is complemented by a ‘join’ or ‘wait’ operation. As shownin Figure 4.6, the fork operation splits the execution of one processinto several and the join operation joins the process executions backinto one.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
