|
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-8A5EC98B-E9AD-5496-9909-7C3B35610785" xml:lang="en"><title>Demand |
|
13 Paging Deadlock Guide</title><shortdesc>Describes deadlocks in the context of demand paging and how to |
|
14 prevent them from occurring. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
15 <section id="GUID-F44CAA63-0225-566F-836C-F5348C0591BD"><title>Introduction</title> <p>A |
|
16 deadlock is when two or more processes have some resources, but not all of |
|
17 the resources required to execute. The resources that are required are held |
|
18 by the other processes, which in turn want the resources that are held by |
|
19 the initial processes. In this state, no process can execute. </p> <p>The |
|
20 classic sign that a deadlock has occurred is that a collection of processes |
|
21 just appear to never do anything i.e. 'just hang'. </p> <p>In the context |
|
22 of demand paging, the resource is a page of RAM that can be paged in or out. |
|
23 If one process wants data in a page of RAM that is paged-in or out by another |
|
24 process, then a potential deadlock condition can occur. </p> <p>Deadlocks |
|
25 are only likely to occur if you are altering or interacting with one of the |
|
26 components used in paging in and out, such as media drivers or the paging |
|
27 sub-system. The majority of user-side code does not need to worry about deadlocks |
|
28 from paging. </p> <p>This guide is most applicable to device side writers |
|
29 and other engineers writing kernel-side code. </p> </section> |
|
30 <section id="GUID-7C628F1C-132F-4327-8248-D018083392E0"><title>Deadlock features</title><p> For a deadlock to occur, |
|
31 four necessary conditions must occur: </p><p> Mutual exclusion condition |
|
32 </p><p> A resource cannot be used by more than one process at a time. </p><p> Hold |
|
33 and wait condition </p><p>One process is holding one resource, but needs |
|
34 another before it can finish. </p><p>No preemption condition </p><p> The |
|
35 resources can only be relinquished by the process holding it. </p><p>Circular |
|
36 wait condition </p><p> One process is holding a resource and wants another |
|
37 resource that is held by another process, which in turn wants access to the |
|
38 resource held by the initial process.</p> </section> |
|
39 <section id="GUID-5758274B-83B1-400D-A0E4-993094066769"><title>Deadlock Prevention</title><p> Since the cause of deadlocks |
|
40 (as far as demand paging is concerned) is due to the paging in and out of |
|
41 RAM, the following points have to be considered: </p><ul> |
|
42 <li><p> Make sure all kernel-side components are always unpaged. </p></li> |
|
43 <li><p> Pinning; new APIs have been added that allows a process to over-ride |
|
44 the demand paging rules as regards to how RAM pages are paged in and out |
|
45 the phone's memory. The name comes from that fact that the RAM page is fixed |
|
46 in the phone's RAM (as if a pin had been stuck into it) until a detached command |
|
47 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> |
|
48 <li><p>Mutex use in device drivers - if the nesting order is violated then |
|
49 deadlock can occur. To overcome this, make sure that all device driver operations |
|
50 that could cause a page fault don't use mutexes. In other words, any access |
|
51 to paged memory while holding a mutex has the potential to cause a deadlock.</p></li> |
|
52 <li><p>Code running in DFC Thread 1 must not access user memory. This DFC |
|
53 thread is used by the implementation of the system timer functionality, hence |
|
54 paging RAM in or out of the system by this thread could cause serious performance |
|
55 problems or a deadlock. </p></li> |
|
56 <li><p> For media drivers, make sure that when the media driver services page-in |
|
57 requests, that the thread that the driver runs in does not also make requests |
|
58 to page-in RAM pages. Because, if this was to occur, then the media driver |
|
59 will not be able to service the page in request and a dead lock would occur. </p></li> |
|
60 </ul> </section> |
|
61 </conbody><related-links> |
|
62 <link href="GUID-ACB79CEF-CA4D-5C96-AFCD-6AD7C7C26C53.dita"><linktext>Thrashing |
|
63 Guide</linktext></link> |
|
64 </related-links></concept> |