Symbian3/PDK/Source/GUID-5F66D3C1-0F7A-478B-AD22-C9848A9DD771.dita
changeset 1 25a17d01db0c
child 3 46218c8b8afa
equal deleted inserted replaced
0:89d6a7a84779 1:25a17d01db0c
       
     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-5F66D3C1-0F7A-478B-AD22-C9848A9DD771" xml:lang="en"><title>SMP
       
    13 Troubleshooting Guide</title><shortdesc>This document describes a few common error patterns to help you
       
    14 identify and correct some of the problems you may have in writing SMP-safe
       
    15 code. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    16 <p>There are two main classes of programming errors that can occur in code
       
    17 running on an SMP device:<ul>
       
    18 <li><p>unsafe assumptions about thread execution order</p></li>
       
    19 <li><p>unsafe assumptions about memory/data sharing.</p></li>
       
    20 </ul>These errors can cause deadlocks or panics on a SMP system, or may cause
       
    21 data corruption or unexpected results. </p>
       
    22 <section id="GUID-BC147BD0-8A99-44D7-AC73-B265C6C0E285"><title>Execution order
       
    23 assumptions</title><p>Most of the errors found in code so far are not unique
       
    24 to SMP, but are more likely to be found on an SMP system. Some existing code
       
    25 makes assumptions about how threads are scheduled and how thread priority
       
    26 affects the sequence of operations across multiple threads.</p><p>For example,
       
    27 one thread makes a request on a server. The developer assumes that the server
       
    28 will complete the request before the calling thread became active again. This
       
    29 is a dangerous assumption as the server might not be ready to run, or could
       
    30 pause while waiting for a resource. This would mean that the scheduler could
       
    31 continue executing the original calling thread before the server has completed
       
    32 the request. </p><p>The above example would be even more likely to be an unsafe
       
    33 assumption on an SMP system because the scheduler could run the server on
       
    34 one CPU core and the original calling thread on another at the same time.
       
    35 This is why it is important for the calling thread to be written in a thread-safe
       
    36 manner which waits for the server to complete the request before continuing
       
    37 into code that requires that request to be complete.</p><ul>
       
    38 <li><p><xref href="GUID-93C75E31-6155-48F1-B99C-92ECD0B2C067.dita">Common Error
       
    39 Patterns - Execution Order</xref> describes a number of common error patterns
       
    40 that have been found during SMP testing.</p></li>
       
    41 <li><p><xref href="GUID-314FAEB5-946C-4090-B6AA-1BEEC9BE8EFB.dita">Common Error
       
    42 Patterns - Case Studies</xref> provides specific examples of common error
       
    43 patterns.</p></li>
       
    44 </ul></section>
       
    45 <section id="GUID-9626880A-4D3A-4C16-8E4C-1256D2D33524"><title>Shared data/memory</title><p>Errors
       
    46 may occur if multiple threads try to update or delete the same memory areas
       
    47 at the same time.</p><p>Good programming practice, whether for single core
       
    48 or multiple core, is to lock objects while they are being updated to prevent
       
    49 them being read by another thread in the middle of an update. For kernel-side
       
    50 code use a lock to ensure that a particular thread has exclusive access to
       
    51 data and interrupts.</p>  </section>
       
    52 <section id="GUID-6EFA3D71-2254-4231-A375-3519F6A13FBF"><title>Flexible Memory
       
    53 Model Problems</title><p>One problem that has been found, though not specifically
       
    54 SMP related, is where the flexible memory model is being used. For global
       
    55 chunks, memory locations are accessed as an offset to a base address. However,
       
    56 each thread may have a different base address for the global chunk: if applications
       
    57 use absolute addresses, they will read the wrong data.</p></section>
       
    58 </conbody><related-links>
       
    59 <link href="GUID-16AED228-539F-4BF7-A7FD-9A01FF1A9A84.dita#GUID-16AED228-539F-4BF7-A7FD-9A01FF1A9A84/GUID-94FDD42D-9D26-4A41-BFB6-57648083EC41">
       
    60 <linktext>SMP - Locking</linktext></link>
       
    61 <link href="GUID-EFE8B65E-AEA6-4C55-B4BA-DE0BFEB1B016.dita"><linktext>Maintaining
       
    62 Data Integrity Using Memory Barriers</linktext></link>
       
    63 <link href="GUID-9781C95D-4606-57FB-9F62-B7CC45DDD968.dita"><linktext>Flexible
       
    64 Memory Model Guide</linktext></link>
       
    65 </related-links></concept>