Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 8
Текст из файла (страница 8)
Since Symbian OS makesuse of hardware memory protection, one application cannot accidentallyoverwrite another’s data. As discussed above, when user-side threadsneed to get privileged access or request kernel-side services, they gothrough a pre-programmed path, implemented by means of a library.The thread is the fundamental unit of execution in Symbian OS.
A process has one or more threads. Each thread executes independently of theothers, but within the same address space. A thread can therefore changememory belonging to another thread in the same process – deliberatelyor accidentally. In consequence, threads are not as well isolated fromeach other as are processes.Threads are pre-emptively scheduled by the Symbian OS kernel. Thehighest-priority thread that is eligible to run at a given time is run by thekernel.
A thread that is ineligible is described as suspended. Threads maysuspend themselves in order to wait for events to happen, and resumewhen one of those events occurs. Whenever threads suspend or resume,the kernel checks which one is the highest ready thread and schedules itfor execution. This can result in one thread being scheduled even whileanother one is running. The consequent interruption of the running threadby the higher-priority thread is called pre-emption, and the possibility ofpre-emption gives rise to the term pre-emptive multitasking.The process of switching execution between one thread and anotheris known as context switching. As in any other operating system, the24A SYSTEM INTRODUCTION TO SYMBIAN OSscheduler in Symbian OS is written carefully to minimize the overheadsinvolved with context switching.Nevertheless, context switching is much more expensive in timingterms than, say, a function call.
The most expensive type of contextswitch is between a thread in one process and a thread in another,because a process switch also involves many changes to the MMUsettings, and various hardware caches may need to be flushed. It’s muchcheaper to switch context between two threads in the same process.User Memory and Memory ManagementAll details of the system’s memory and memory manipulations, includinglow-level memory management, are encapsulated in a kernel componentcalled the memory model. For example, it is the memory model thatimplements all necessary operations for context switching, while the policy for doing so is implemented in the kernel scheduler. For further detailson the internals of the memory model and its usage, see [Sales 2005].Every user-side program on Symbian OS is instantiated in a processthat has at least one thread, the main thread.
When the main thread exits,the process terminates. A process can be a collection of many relatedthreads. For a program to execute, every thread needs a stack and possiblya heap. As mentioned previously, in Symbian OS each user-side threadis assigned two stacks, one for supervisor-mode calls and one for normalexecution. By default these stacks are 4 KB and 8 KB respectively.While stacks are allocated by the kernel (via the memory model) onthread creation, the kernel does not create a heap for user-side threads.
InEKA2, user-side threads are responsible for creating their own heaps oncreation, or they may share an existing heap (usually the process’s mainthread heap), since all of the threads in a process share the same addressspace.By default, a process’s main thread is created with a heap; however,there are interfaces for a process to override the normal local heapcreation mechanism and heap allocator functions. This is something thatprogrammers may choose to do if they have specific memory allocationrequirements (for example, for games or signal-processing algorithms)that would be better served by a custom memory allocator, rather thanthe default general-purpose one.For every process, heaps, stacks, static data and any program instructions that are not run from ROM all need to be placed in RAM.
Themechanism by which the Symbian OS memory model allocates and manages memory is called chunks. Chunks are containers for physical RAMpages mapped to virtual addresses. In terms of addressing and accessing,a chunk appears as a contiguous virtual memory region. Its apparent sizemay be larger than the physical memory actually committed for usage,thus not all of the virtual memory region is necessarily accessible.SYMBIAN OS BASICS25In order to achieve the deterministic behavior necessary for real-timeprogramming, there is a maximum number of chunks (16 by default) thatmay be mapped to each process.
On initial creation, depending on thehardware used, a process will have all its user-mode stacks as well as itswritable static data placed on the same chunk. Protection between thestacks used by different threads is achieved by leaving unmapped pagesbetween adjacent stacks. At least one additional chunk is used for threadheaps, and another for storing any executable code that is not executedin place from ROM.
If the process makes use of shared libraries that havewritable static data, it is assigned yet another chunk for this data.Chunks can be shared by being mapped onto more than one process.This can be used as a means of communication without copying dataacross process boundaries.Symbian OS ServersAs with other microkernel architectures, a Symbian OS server is a program(usually without a user interface) that manages and mediates access toone or more resources or services.A server provides a programming interface so that its clients can gainaccess to its services.
A server’s clients may be applications or otherservers. Each server generally runs in its own process (although for performance reasons, closely related servers may run in the same process), sothat the boundary between a server and its clients is a process boundary.This provides a strong assurance of server integrity. As shown in Figure 2.3,to communicate with a server, its clients need to employ client–serverinter-process communication (IPC) mechanisms (see Chapter 8). Such IPCmechanisms are encapsulated in the client APIs of each server.Response dataClientIPC sessionServerResourceIPC sessionClientFigure 2.3Client–server communicationsThe isolation between a server and its clients is of the same orderas the isolation between a kernel and user-mode programs, but serversare much easier to program and work with. Symbian OS uses servers to26A SYSTEM INTRODUCTION TO SYMBIAN OSprovide many services that, on monolithic kernel systems, are providedby the kernel or device drivers [Tanenbaum and Woodhull 1997].Symbian OS Inter-Process CommunicationThe channel of communication between a client and a server is knownas a session.
Session-based communication comprises client requestsand server responses. Within the kernel, which mediates all messages,such request–response pairs are associated through session objects. Aclient can have multiple sessions open with any given server if the serversupports it. A session can be shared by more than one client thread tominimize the use of kernel resources, again if the server supports it.Session-based client–server communication is aptly designed forevent-driven user-initiated interactions, typically between an applicationthat interacts with the user and a server that serializes many applicationrequests to a resource.
This is not the only IPC mechanism available:EKA2 programs may also make use of message queues, shared chunksand publish–subscribe to communicate with each other. Symbian OSIPC mechanisms are discussed in detail in Chapter 8.Power ManagementPower management is the single most important difference betweena desktop and a portable system. Battery life, even with rechargeablebatteries, makes a difference to how the user uses and thinks of themobile phone. Symbian OS ensures that power is used efficiently.Certain parts of the system should still be able to run while the phoneis in low power mode and apparently off.
For example, when an alarm isdue, the phone should turn on so that the alarm can sound.A mobile phone needs to react to an incoming call or SMS, whichwould not happen if it were fully turned off; the system should be able torespond by changing from low-power to active mode. Even if all poweris removed suddenly, the system should do what it can to save criticalinformation, so that there is a possibility of a warm boot rather than acold boot when power returns.As an application or server programmer, your task is easier than thatof the kernel-side programmer, but you still have to be aware of powermanagement issues.
You have to write your programs efficiently, to makebest use of the phone’s scarce resources. For example, as with all portablebattery-powered devices, polling is considered a cardinal sin.Power management becomes more complicated the deeper you delveinto the system. For a device driver programmer, power management ismore complex than simply having the phone on, off or in sleep mode.Even though the user may think the phone is off if the display is turnedoff, it may be processing or handling events behind the scenes.SYMBIAN OS BASICS27Each hardware component should be responsible for its own powermanagement. For example, a communications link driver should turn thephysical device off if it’s not needed.
At times, the kernel will turn partsor even the whole of the CPU off, if all threads are waiting for an event.At the same time, every possible step must be taken to ensure that userdata is retained, even in the most difficult power-loss situations.TimersSymbian OS timers are maintained on two levels, at nanokernel andmicrokernel level. Application developers are principally interested inthe timer services provided by the microkernel, such as those offered bythe RTimer class.
As stated earlier, the Timer thread is the kernel threadresponsible for managing timer queues and alarms, for example whenrequesting an alarm by means of a call to RTimer::At().Executables and Shared LibrariesIn general, when a program is about to be executed by an operatingsystem, it is loaded into memory (RAM). For the OS to be able tounderstand the executable image of a program, it must be packaged ina specific format known to the OS loader.
On Symbian OS EKA2, thisformat is based on the ELF (Executable & Link Format) standard.Different parts of the program are mapped to different parts of thememory which the operating system allocates for use by the process. Anexecutable image must package such program information accordingly.• The program’s processor instructions are stored together in what isusually referred to as a text section.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
