<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-8A5EC98B-E9AD-5496-9909-7C3B35610785" xml:lang="en"><title>Demand
Paging Deadlock Guide</title><shortdesc>Describes deadlocks in the context of demand paging and how to
prevent them from occurring. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<section id="GUID-F44CAA63-0225-566F-836C-F5348C0591BD"><title>Introduction</title> <p>A
deadlock is when two or more processes have some resources, but not all of
the resources required to execute. The resources that are required are held
by the other processes, which in turn want the resources that are held by
the initial processes. In this state, no process can execute. </p> <p>The
classic sign that a deadlock has occurred is that a collection of processes
just appear to never do anything i.e. 'just hang'. </p> <p>In the context
of demand paging, the resource is a page of RAM that can be paged in or out.
If one process wants data in a page of RAM that is paged-in or out by another
process, then a potential deadlock condition can occur. </p> <p>Deadlocks
are only likely to occur if you are altering or interacting with one of the
components used in paging in and out, such as media drivers or the paging
sub-system. The majority of user-side code does not need to worry about deadlocks
from paging. </p> <p>This guide is most applicable to device side writers
and other engineers writing kernel-side code. </p> </section>
<section id="GUID-7C628F1C-132F-4327-8248-D018083392E0"><title>Deadlock features</title><p>        For a deadlock to occur,
four necessary conditions must occur:  </p><p> Mutual exclusion condition
 </p><p>  A resource cannot be used by more than one process at a time.  </p><p> Hold
and wait condition  </p><p>One process is holding one resource, but needs
another before it can   finish. </p><p>No preemption condition  </p><p> The
resources can only be relinquished by the process holding it.  </p><p>Circular
wait condition </p><p> One process is holding a resource and wants another
resource that is  held by another process, which in turn wants access to the
resource held by the  initial process.</p> </section>
<section id="GUID-5758274B-83B1-400D-A0E4-993094066769"><title>Deadlock Prevention</title><p>      Since the cause of deadlocks
(as far as demand paging is concerned) is  due to the paging in and out of
RAM, the following points have to be        considered:  </p><ul>
<li><p> Make sure all kernel-side components are always unpaged. </p></li>
<li><p> Pinning; new APIs have been added that allows a process to over-ride
  the demand paging rules as regards to how RAM pages are paged in and out
the phone's memory. The name comes from that fact that the RAM page is fixed
in the phone's RAM (as if a pin had been stuck into it) until a detached command
is  executed (unpinned). This is implemented by using the new  <xref href="GUID-A3CC1D95-4681-3349-A67C-F113A614041D.dita#GUID-A3CC1D95-4681-3349-A67C-F113A614041D/GUID-0DCAB25E-5A99-35EB-9F75-E9C275EE9E17"><apiname>DLogicalChannel::SendMsg()</apiname></xref> method. </p></li>
<li><p>Mutex use in device drivers - if the nesting order is violated then
deadlock can occur. To overcome this, make sure that all device driver operations
that could cause a page fault don't use mutexes. In other words, any  access
to paged memory while holding a mutex has the potential to cause a deadlock.</p></li>
<li><p>Code running in DFC Thread 1 must not access user memory. This DFC
thread is used by the implementation of the system timer functionality, hence
paging RAM in or out of the system by this thread could cause serious performance
problems or a deadlock.   </p></li>
<li><p> For media drivers, make sure that when the media driver services page-in
requests, that the thread that the driver runs in does not also make   requests
to page-in RAM pages. Because, if this was to occur, then the media  driver
will not be able to service the page in request and a dead lock would occur. </p></li>
</ul> </section>
</conbody><related-links>
<link href="GUID-ACB79CEF-CA4D-5C96-AFCD-6AD7C7C26C53.dita"><linktext>Thrashing
Guide</linktext></link>
</related-links></concept>