Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 15
Текст из файла (страница 15)
Onlyif there is no more power available for the device should the subsystemfail to provide a location.6To achieve this, the following strategies are employed by the LBSsubsystem:• Mobile devices that support emergency network location requestsmust choose the Full Mode configuration of the LBS subsystem.This ensures that, when the device is started, the LBS subsystem isincluded in the boot-up sequence. Hence all five of the LBS processesare pre-allocated at a default cost of at least 105–170 KB of RAM.76 Power7 Seeis an ephemeral resource and cannot be pre-allocated for one particular use.Appendix A for more details.IMMORTAL61However, more than just memory has been reserved as this approachalso ensures that any dynamic configuration data is available andthat there’s no subsequent possibility of a corrupt INI file generatingadditional errors at just the wrong moment.• Messages between components within the LBS subsystem are sentvia Publish and Subscribe (see page 114).
This is because, when thesubsystem is created, each of its components are able to pre-allocateall of the resources it needs, by calling RProperty::Define(), tomaintain its IPC channels even if the system is out of memory.For instance, this means that the Network Request Handler, whichprocesses location requests from remote parties, can guarantee that itis able to send commands directly to the A-GPS module. Similarly,once the A-GPS module has obtained the position data from the GPShardware it can guarantee to publish the location data and have itreceived by the location server.• Only the immortal resources required to generate a location are preallocated.
For instance, under normal circumstances the subsystemcan be configured so that the user is notified before a location issent over the network. However, in out-of-memory situations thisnotification to the user is not guaranteed since it was decided that thecomplexity involved in arranging for sufficient immortal resources todo the job wasn’t necessary.
This is because an end user is unlikely tocomplain if they weren’t informed that the emergency services weretold where to rescue them from!8Other Known Uses• Camera HardwareSome types of hardware usually require resources to be allocated bytheir device driver when a device is booted. For instance, large-megapixel cameras require correspondingly large contiguous memorybuffers so the device driver always has sufficient memory to store animage. This memory is a significant proportion of the entire memoryof the device and needs to be contiguous for performance reasons. Ifcameras didn’t pre-allocate the memory, they would run a high risk offailing to allocate the memory on demand due to fragmentation of thedevice’s RAM, even if the total memory available would be enoughto satisfy the request.9Interestingly, camera applications normally do not choose to reservesufficient disk space to store a picture.
This is because the disk spacerequired is normally a smaller proportion of the total available but8If it is not an emergency then the inability to notify the end user would prevent thelocation being sent over the network.9 See the discussion on this subject in Variable Allocation [Weir and Noble, 2000].62RESOURCE LIFETIMESalso because the consequences of being out of disk are not as severesince the picture isn’t lost.
If this happens then the end user can findadditional disk space in which to save the picture by inserting anothermemory card or deleting unnecessary files to make space.• File ServerThe File Server is started when a device boots up and is not stoppeduntil the entire device shuts down. This is because the RAM usedby the server is deemed an acceptable trade-off for providing quickresponses to clients since it is a heavily used service.Variants and ExtensionsNone known.References• Fail Fast (see page 17) describes an error-handling strategy oftenemployed to deal with a failure to allocate the immortal resourceduring initialization.• Lazy Allocation (see page 63) describes an alternative to this pattern.• Variable Allocation [Weir and Noble, 2000] describes an alternativeto this pattern.• Eager Acquisition [Kircher and Jain, 2004] describes a variation of thispattern.LAZY ALLOCATION63Lazy AllocationIntentAllocate resources, just in time, when they are first needed to improvehow they are shared across the system.AKALazy Initialization, Lazy Allocation, On-Demand Loading, DeferredLoadingProblemContextThe functionality of your application or service may require a resourcebut it is not needed immediately nor is it a critical requirement.SummaryYou have to resolve one or more of the following:• You don’t know if a resource will be needed when your applicationor service starts.• The resources you are interested in are scarce and need to be sharedacross the system.• There is a long period between your application or service startingand first use of the resource.• You’d like to be able to start your component as quickly as possible.DescriptionThe temptation you’ll face is to ensure that all the resources that maybe needed for your component are allocated early in the lifetime of thecomponent (e.g.
at construction). This approach seems straightforwardand is easy to understand because all the resources are allocated upfront.However, for resources which have a significant size, using Immortal(see page 53) can be problematic as the resources will not be available toothers in the system.
If a particular component allocates a large proportionof the available resources then all the time that the component is runningit is preventing all other components in the system from using thoseresources.Although the allocated resource usage constraints are a significantproblem, the time taken to allocate a resource might be an additionalchallenge.
While allocating one single resource, such as a single block of64RESOURCE LIFETIMESmemory or a single server connection, might take an insignificant time,many resource allocations can quickly add up to a significant amount ofprocessing time or eat up a significant proportion of that type of resourcesin the whole system. This is particularly significant on a mobile device,where resources are constrained.Even disregarding the extra power use, allocating resources when theymight not be needed by the component can have an impact on the userexperience. A user is not going to be happy with a maps application ifit shows a loading screen for half a minute at start-up as it allocates theconnection to the server to retrieve map information which is alreadycached on local media.One way to solve this problem would be to use the Mayfly approachbut this has the drawback of needing to be explicitly managed by theresource client. Ideally a solution would have the ease of use of Immortal(see page 53) but without preventing the resource from being shared untilabsolutely necessary.ExampleThe Communication Infrastructure, known as Comms-Infras, within Symbian OS supports multiple protocol modules via a plug-in system.
Eachplug-in covers a different protocol, such as TCP/IP or the Bluetooth AudioVideo Control Transport Protocol. The Communications Provider Module(CPM) interface is used to define each of these protocols. A straightforward approach to the lifetime of the resources needed by each protocolmodule would be to use Immortal (see page 53). However each protocolis generally non-trivial and can use 10s or 100s of kilobytes of RAMin addition to other resources.
If an end user never makes use of one,or more, of these protocols, a likely scenario if their phone is the onlydevice supporting Bluetooth that they own, then the resources used bysuch a protocol are effectively wasted. These resources would be moreeffectively used elsewhere.For more details on Symbian OS communications, see [Campbellet al., 2007].SolutionLazy allocation is based on the tactic of the resource client using aProxy [Gamma et al., 1994] to access the resource, rather than usingthe resource directly. The resource client allocates the Proxy, or lazyallocator as it is known here, immediately, as in Immortal (see page 53),for simplicity and delegates the actual management of the lifetime of theresource to the lazy allocator.
This allows the lazy allocator to delay theallocation of the actual resource until the first time it is needed.This pattern is written from the point of view of keeping a resource,once allocated, for as long as possible. This is because there are otherLAZY ALLOCATION65patterns that can be composed with this one that discuss de-allocationstrategies; for simplicity, an Immortal (see page 53) approach is taken tode-allocation.StructureThe resource, resource provider and resource client are as explainedin the introduction to this chapter. The one additional object in thisstructure is the important part of this pattern.
Instead of the resource clientallocating the resource directly from the resource provider, a small Proxyobject, the lazy allocator, is placed between the two (see Figure 3.3).Resource Client1Allocates on initialization*ResourceProviderLazy Allocator+UsesUseL()*1 ++AllocateL()Deallocate()1Allocates on demand0..1Resource+UseL()Figure 3.3Structure of the Lazy Allocation patternThe main responsibility of the lazy allocator is to delay the allocation ofthe resource from the resource provider until it is required. The lazy allocator provides the same interface as the resource itself so that the resourceclient interacts with the lazy allocator just as it would with the resource.The resource client is expected to treat the lazy allocator as an immortalresource.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
