1 <?xml version="1.0" encoding="utf-8"?>

     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

     3 <!-- This component and the accompanying materials are made available under the terms of the License 

     4 "Eclipse Public License v1.0" which accompanies this distribution, 

     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

    12 <concept id="GUID-3A625B23-354E-5CB4-98CF-FF53AD724FA0" xml:lang="en"><title>Dealing with Demand Paging</title><shortdesc>When demand paging is used, the contents of memory are

    13 available to a program when they are required (“on demand”). When

    14 the contents are no longer required, the RAM can be used for other

    15 content.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

    16 <p>Demand paging is a change to how the kernel can use RAM from Symbian

    17 platform v9.3. This topic describes the possible results for base

    18 port. </p>

    19 <p>When demand paging is used, the contents of memory are available

    20 to a program when they are required - that is, 'on demand'. When the

    21 contents are no longer required, the RAM can be used for other content.

    22 In this way, the total RAM required to store content is less than

    23 if it were all permanently available. </p>

    24 <p>The Device Driver Guide provides <xref href="GUID-469EC7BB-8697-57FE-A487-016882A0BEA8.dita#GUID-469EC7BB-8697-57FE-A487-016882A0BEA8/GUID-E382AA71-8BB5-5567-8578-51598D3131FD">Suggested techniques for mitigating the effects of demand paging</xref> for writers of device drivers. These recommendations can result

    25 in a more ‘multithreaded’ base-port. This may have the following impact

    26 that needs to be considered: </p>

    27 <ul>

    28 <li id="GUID-DB6CC462-FB46-5D3B-8BAA-5B21FA06AF9D"><p>A base-port

    29 component may provide services to device drivers, exposing to them

    30 a shared resource; either hardware or software: </p> <ul>

    31 <li id="GUID-6B9E9433-EA19-54AE-B7A5-6E2C3341723B"><p>hardware - may

    32 be a hardware controller whose non-instantaneous operation, once initiated,

    33 cannot be disturbed until it completes </p> </li>

    34 <li id="GUID-92AD6E2B-34CC-59B4-8D52-FD739C3DD841"><p>software - may

    35 be a list of requests for services. </p> </li>

    36 </ul> </li>

    37 <li id="GUID-45F7D284-C216-5684-8C7B-2958C809B1BC"><p>A hardware component

    38 has a control interface that can be used by a number of drivers. Operations

    39 on the control interface although near instantaneous, are not atomic

    40 and cannot be interrupted. </p> </li>

    41 </ul>

    42 <p>In the case of the base-port component, when the state of a resource

    43 needs to be protected from the effects of pre-emption for a non-negligible

    44 period of time, the recommended approach is to use mutual exclusion,

    45 protecting the resource with a mutex: unless there is any chance that

    46 the same driver may trigger the same operation before the previous

    47 one completed. For example, when operations are non-blocking and happen

    48 in a context different from the initiator’s, a <xref href="GUID-D5B555DA-3D17-3ED2-A931-CB35BD93A953.dita"><apiname>NFastMutex</apiname></xref> should suffice. </p>

    49 <p>An example of the hardware component situation is a set-clear control

    50 interface, where a pair of registers (one containing the bits to be

    51 set, the other the bits to be cleared) have to be written to produce

    52 the desired change. If the operation is pre-empted after bits are

    53 set but before they are cleared for a desired final output, and a

    54 new set-clear operation is initiated, the final state of the interface

    55 may be undetermined. Pre-emption protection in this case is achieved

    56 by simply locking the Kernel using <xref href="GUID-3A3C08F3-3D33-3D9E-80E7-7855C7B21E02.dita#GUID-3A3C08F3-3D33-3D9E-80E7-7855C7B21E02/GUID-7CBBF72B-4519-38DD-92CA-38AF636AFD8A"><apiname>NKern::Lock()</apiname></xref> before the operation starts and unlocking it with <xref href="GUID-3A3C08F3-3D33-3D9E-80E7-7855C7B21E02.dita#GUID-3A3C08F3-3D33-3D9E-80E7-7855C7B21E02/GUID-A1A42137-906C-30F1-AF61-4F786FC372DE"><apiname>NKern::Unlock()</apiname></xref> after it completes. If the interface is to be used from an interrupt

    57 context disabling all interrupts is sufficient to protect against

    58 thread concurrency. </p>

    59 </conbody><related-links>

    60 <link href="GUID-90B5FDD9-7D59-5035-BF53-2B177655DCD6.dita"><linktext>Migration

    61                 Tutorial: Demand Paging and Internal MMC Cards</linktext>

    62 </link>

    63 <link href="GUID-EB2566BD-8F65-5A81-B215-E8B05CFE21C3.dita"><linktext>Migration

    64 Tutorial: Demand                 Paging and Media Drivers</linktext>

    65 </link>

    66 </related-links></concept>