The Symbian OS (779886), страница 16
Текст из файла (страница 16)
While this is in keeping with a full object-orientedapproach, which objectifies machine resources in order to make themthe fundamental objects in the system, it can also cause confusion.In Symbian OS, threads and processes are defined in [Sales 2005,Chapter 3] as follows:58INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OS• threads are the units of execution which the kernel scheduler schedules and runs• processes are collections of at least one but possibly multiple threadswhich share the same memory address space (that is, an addressmapping of virtual to physical memory).Processes in other words are units of memory protection. In particulareach process has its own heap, which is shared by all threads within theprocess.
(Each thread has its own stack.)A process is created as an instantiation of an executable image file(of type EXE in Symbian OS) and contains one thread. Creation ofadditional threads is under programmer control. Other executable code(for example, dynamically loaded code from a DLL file) is normallyloaded into a dynamic-code segment attached to an existing process.Loading a DLL thus attaches dynamic code to the process context of theexecuting thread that invokes it.Each server typically runs in its own process,10 and its clients run intheir own separate processes. Clients communicate with the server acrossthe process boundary using the standard client–server conventions forinterprocess communication (IPC).11As Peter Jackson comments, Symbian OS falls somewhere betweenconventional operating system models in its thread and process model.Peter Jackson:Most of the threads versus processes issues are to do with overhead.
In someoperating systems, processes are fairly lightweight, so it’s very easy to spawnanother process to do some function and return data into a common poolsomewhere. Where the process model is more heavyweight and the overheadof spawning another one is too great, then you invent threads and you letthem inherit the rest of the process, so the thread is basically just a way ofscheduling CPU activity. In Symbian OS, you can use whichever mechanismis appropriate to the requirements.Server-Side and Client-Side OperationsTypically a server is built as an EXE executable that implements theserver-side classes and a client-side DLL that implements the client-sideinterface to the server.
When a client (either an application or another10There are some exceptions for reasons of raw speed.[Sales 2005] defines the Symbian OS client–server model as inter-thread communication (ITC), which is strictly more accurate than referring to interprocess communication(IPC). However, arguably the significance of client–server communications is the crossingof the process boundary.11THE KEY DESIGN PATTERNS59system service) requests the service, the client-side DLL is attached tothe calling process and the server-side executable is loaded into a newdedicated process (if it is not already running).Servers are thus protected from their clients, so that a misbehavingclient cannot cause the server to fail.
(The server and client memoryspaces are quite separate.) A server has responsibility for cleaning up aftera misbehaving client, to ensure that resource handles are not orphaned ifthe client fails.At the heart of the client–server pattern therefore is the IPC mechanismand protocol, based on message passing, which allows the client in itsprocess, running the client-side DLL, to communicate via a sessionwith the server process. The base classes from which servers and theirclient-side interfaces are derived encapsulate the IPC mechanisms.The general principles are as follows:12• The client-side implementation, running in the client process, manages all the communications across the process boundary (in thetypical case) with the server-side implementation running in theserver process.• The calling client connects to the client-side implementation andcreates a session, implemented as a communications channel andprotocol created by the kernel on behalf of the server and client.• Client sessions are typically created by calling Connect() andare closed using Close() methods, in the client-side API.
Theclient-side calls invoke the standard client–server protocol methods, for example RSessionBase::CreateSession() and RProcess::Create(). On a running server, this results in the clientsession being created; if the server is not already running, it causesthe server to be started and the session to be created.• The client typically invokes subsessions that encapsulate the detailedrequests of the server-defined protocol.
(In effect, each client–servermessage can be thought of as creating a subsession.)• Typically, client-side implementations derive from RSessionBase,used to create sessions and send messages.• Typically, the server side derives from CServer.Servers are fundamental to the design of Symbian OS, and are (as themantra has it) the essential mechanism for serializing access to sharedresources, including physical hardware, so that they can be shared bymultiple clients.12The best description is [Stichbury 2005, Chapter 12].60INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OSAndrew Thoelke:It’s not so much that there is a server layer in the operating system as ahierarchy. It’s very much a hierarchy and there are a lot of shared services.Some of them are shared by quite a few components and some of them reallysupport just a very small part of the system, and of course those shared servicesmay build on top of one or more client–server systems already.Client–server is a deep pattern that is used as a structuring principlethroughout the system.Asynchronous ServicesAnother deep pattern in the system is the design of services to beasynchronous.System responsiveness in a multitasking system (the impression thatapplications respond instantly and switch instantly) depends on asynchronous behavior; applications don’t wait to finish processing oneaction before they are able to handle another.The alternatives are blocking, or polling, or a combination of both.In a blocking request (the classic Unix pattern), the calling programmakes a system call and waits for the call to return before continuing itsprocessing.
Polling executes a tight loop in which the caller checks to seeif the event it wants is available and handles it when it is. (Polling is usedby MS-DOS, for example, to fetch keystrokes from the keyboard.)Blocking is unsatisfactory because it blocks others from accessing thesystem call which is being waited on, while it is waiting. Polling isunsatisfactory because code which is functionally idle, waiting for anevent, is in reality not idle at all, but continuously executing its tightpolling loop.Blocking reduces responsiveness.
Polling wastes clock cycles, whichon a small system translates directly to power consumption and batterylife.Charles Davies:Asynchronous services was driven by battery life. We were totally focused onthat. For example on one of the Psion devices, we stopped the processor clockwhen it was idle.
I don’t know if that was innovative at the time. We certainlydidn’t copy it from anybody else, but we had a static processor. Usually in anidle process, the operating system is doing an idle loop. But we didn’t do that,we stopped the clock on the processor and we turned the screen off, and thatwas fundamental to the design.Typically, client–server interactions are asynchronous.THE KEY DESIGN PATTERNS61The Plug-in Framework ModelA final high-level design pattern, the plug-in framework model is usedpervasively in Symbian OS, at all levels of the system from the UIFramework at the top to the lowest levels of hardware abstraction at thebottom.A framework (as its name suggests) is an enclosing structure.
A plug-inis an independent component that fits into the framework. The frameworkhas no dependency on the plug-in, which implements an interface definedby the framework; the plug-in has a direct, but dynamic, dependency onthe framework.Frameworks are one of the earliest design patterns (going back to thetime before design patterns were called design patterns, in fact) [Johnson1998]. While, in principle, nothing limits them to object-oriented design,they lend themselves so naturally to object-oriented style that the two arestrongly identified. A key principle of good design (again, not limited toobject-oriented design but closely identified with it) is the separation ofinterface from implementation.
On a small scale, this is what designingwith classes achieves: a class abstracts an interface and its expectedbehavior and encapsulates its implementation. Frameworks provide amechanism for this kind of abstraction and encapsulation at a higher level.As is often said, frameworks enable a complete design to be abstractedand reused.13 Frameworks are therefore a profound and powerful way ofconstructing an object-oriented system.In detail, a framework in Symbian OS defines an external interface tosome part of the system (a complete and bounded logical or functionalpart) and an internal plug-in interface to which implementers of theframework functionality (the plug-ins) conform. In effect, the frameworkis a layer between a calling client and an implementation.
In the extremecase, a ‘thin’ framework does little more than translate between the twointerfaces and provide the mechanism for the framework to find and loadits plug-ins. A ‘thicker’ framework may do much more, providing plug-ininterfaces which are highly abstracted from the external visible clientinterface. Symbian OS contains frameworks at both extremes and mostpoints in between.Because in Symbian OS a framework exposes an external interfaceto a complete, logical piece of the system, most frameworks are alsoimplemented as servers.As well as providing interface abstraction and separation from implementation, and flexibility through decoupling, frameworks also provide anatural model for functional extension.
This approach is used for exampleby the telephony-server framework to provide an open-ended design. Thecore framework supports generic telephony functionality based arounda small number of generic concepts. Framework extensions implement13A framework is ‘reusable design’ as [Johnson 1998] puts it.62INTRODUCTION TO THE ARCHITECTURE OF SYMBIAN OSthe specialized behaviors which differentiate landline from mobile telephony, data from voice, circuit- from packet-switched, GSM from CDMA,and so on.As well as this ‘horizontal’ extension of the range of functionalityof the framework, such a plug-in also defines the interfaces whichare implemented ‘vertically’ by further plug-ins that provide the actualservices.Because the plug-in framework model is pervasive, Symbian OS provides a plug-in interface framework.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
