Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 40
Текст из файла (страница 40)
The client session replaces the cacheif the client requests a different time zone. It also observes the serverfor changes other clients make to the selected zone and flushes thecache when that happens.CLIENT–SERVER209• Co-location of Related ServicesContext switching between threads is expensive; context switchingbetween threads in different processes is even more expensive becauseof MMU21 changes and the various caches to be flushed.
There is alsoan extra cost to data transfer between threads in different processesbecause of the mapping that needs to be done. Where it is appropriatethat servers should be co-located in the same process to minimizethis cost, it should be done. A group of servers that depend heavilyon each other’s resources and that can be trusted to collaborate in thesame process space is one example. The Communications frameworkin Symbian OS is modeled after this strategy.
Another example is aserver that only serves one specific application. The latter server isbest located inside its application’s process.• Deferred Server TerminationIn situations where clients of a transient server come and go frequently,it is important, for performance reasons, that the server deferred itstermination until some definite time after the last session closes. Thisis especially desirable where the cost of creating and initializing theserver’s resources are very high.
Lazy De-allocation (see page 73) canbe used to address this by using a timer running alongside the serverthat destroys the server, and itself, after a set timeout following theclosure of the last session.• Delegate Child Active ObjectsTo provide performance guarantees to all its clients, it is necessaryfor a server to delegate long-running requested activities to childactive objects so it is free to handle the next request. Often thesechildren are Asynchronous Controllers (see page 148) running in theserver’s thread.
Sometimes it is best that they have their own threadof execution.References• Some related, but contrasting, architectural patterns are Peer-toPeer [Buschmann et al., 1996] and Master–Slave [Buschmann et al.,1996].• An implementation of the client–server architecture may use standardindustry patterns such as:• Proxy [Gamma et al., 1994] as an object adaptor of the server• Memento [Gamma et al., 1994] to persist calls on the server• Pipes [Buschmann et al., 1996] for communication.21 en.wikipedia.org/wiki/Memorymanagement unit .210PROVIDING SERVICES• A number of Symbian OS patterns are also used:• Active Objects (see page 133) is used to efficiently handle servicerequests from multiple clients.• Request Completion (see page 104) is used by the server to informclients of when their requests have been completed.• Escalate Errors (see page 32) is extended so that errors which occurin the server when handling a client’s request are passed back tothe client.• The client–server framework chapter in [Harrison and Shackman,2007] gives comprehensive coverage of how the pattern is codified inSymbian OS.• [Stichbury, 2004] also covers the client–server framework.• [Heath, 2006] contains a chapter describing how to design a secureserver.• Template code for a transient server is available fromdeveloper.symbian.com/main/oslibrary/cpp papers/advanced.jsp.• The Symbian Developer Library contains an overview of the SymbianOS client–server architecture as well as example code:• Symbian Developer Library Symbian OS guide Base UsingUser Library (E32) Inter Process Communication Client/ServerOverview• Symbian Developer Library Examplescode Client/Server example code.User library exampleCOORDINATOR211CoordinatorIntentCo-ordinate state changes across multiple interdependent components byusing a staged notification procedure that maximizes flexibility.AKAState-Aware Components, Staged System TransitionProblemContextYou need to synchronize a collective change across many related components in different processes whilst respecting their layering.22Summary• You need to ensure that the dependencies between components arerespected by having a structured system of notifications.• You’d like the state change to be completed as quickly as possible.• To make the testing and maintenance of your software easier youwant the components being notified of the state changes to be looselycoupled both with respect to each other and to the service informingthem of the change.
In particular, it should be easy to change whichcomponents are taking part in the notifications.• A transparent means of inter-process communication (IPC) is needed.DescriptionWhen synchronizing a collective change across multiple components,you’re going to need to perform a series of operations. They might be aswide-ranging as needing to notify components in the system that the freesystem memory is low or relatively focused, such as informing a collectionof UI components in an application that a list has been updated.
The morecomponents that need to react to such a change increases the likelihoodthat there are pre-existing dependencies between some of them.Some dependencies between components can be straightforward, suchas starting a new process with no further interactions between the creatorand the created processes. More often, you will find that they require moredirect cooperation between them. For components in different processes,they will need to use one of the many IPC mechanisms available inSymbian OS. Examples of commonly used mechanisms are Client–Server22 Asin the Layers pattern [Buschmann et al., 1996].212PROVIDING SERVICES(see page 182) and Publish and Subscribe (see page 114).
However,regardless of the method used, each sets up a dependency between thetwo components as a result of the communication. Sometimes thesedependencies might be obvious, such as with RASCliSession where itis clear that it represents a client session with a server, in this case, thealarm server.
In other cases, the dependency on an external componentmight be less obvious, such as with CMsvEntry, a message server entity,where the internal use of a client–server session by the class is hiddenfrom the client.The chain of dependencies between the components can quicklycomplicate how your collective change can be performed. Imaginea situation where a client and a service both de-allocate memory inresponse to a low memory notification. If the client needs to get theservice to perform some actions, such as saving data on its behalf, thenthere is little point in getting the service to de-allocate memory first.When the client uses the service to save data, the service could well endup re-allocating the memory.
In the UI layer, for example, there is littlepoint in notifying a list to redraw itself if a different and overlapping UIcomponent, responding to the same change, forces the list to be redrawnagain.If handled incorrectly, these dependencies can at best reduce performance and, at worst, lead to deadlock, where each component is stuckwaiting for other components, or live-lock, where a series of componentscontinuously trigger changes in other components.One way we could handle these dependencies could be to introduceexplicit dependencies between the components. In this situation, youwould need to maintain a list of root nodes such that when a changewere needed each of these root nodes would be notified.
Each root nodewould then be responsible for notifying its dependent children followedby the children in turn notifying the change to all of their dependents andso on.Putting such a scheme into place is straightforward to start withand does makes it easy to understand the relationships between allthe components involved in the change. However this approach has asignificant disadvantage of causing the components to be tightly coupledsuch that it would be very difficult to move or remove a root node fromthe notifications without adversely affecting its children. On an openoperating system such as Symbian OS, with components on a devicecoming from a wide range of companies and individuals ranging fromSymbian and the device manufacturers to network operators and thirdparty application developers, such a tightly coupled scheme would notbe acceptable.Another alternative would be to have each component regularly pollthe value of the state they’re interested in.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
