--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/PDK/Source/GUID-16AED228-539F-4BF7-A7FD-9A01FF1A9A84.dita	Fri Jan 22 18:26:19 2010 +0000
@@ -0,0 +1,83 @@
+<?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-16AED228-539F-4BF7-A7FD-9A01FF1A9A84" xml:lang="en"><title>Locking</title><shortdesc>This document describes SMP locks and outlines the need of introducing
+locks in the code.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>Locks are used to synchronize the data between threads in the kernel. They
+can be also used to synchronize access to data in user side threads In SMP,
+threads are executed in parallel, which means that if locks are not applied
+to the code it could result in a race condition. Race conditions lead to system
+crashes and data corruptions. </p>
+<section id="GUID-6DA960AD-4E33-4B15-B960-F8077530AC88"><title>Locking Granularity</title><p>An
+important property of a lock is its granularity. The granularity is a measure
+of the amount of data the lock is protecting. There are two different granularities
+for locks:</p><ul>
+<li><p><b>Coarse-Grained Locks</b> enclose a large area of shared code or
+multiple areas of unrelated data. The lock reduces the number of threads that
+run concurrently resulting in serial execution making the code behave like
+a single thread process. Coarse locks are applied in parallel. One lock can
+be applied to each kernel subsystem.</p></li>
+</ul><p>The following diagram illustrates how a Coarse-Grained Lock covers
+many parts of code. It not only simplifies the locking action itself but also
+frees developers from having to load all the members of a code in order to
+lock them. In order to get concurrency in the operating system, the operating
+system must allow more than one process (or interrupt) to execute at the same
+time. To do this, we divide the OS into sections and give each section a lock.
+For a small number of processors, we only need a small number of locks, each
+covering a large region of the OS. This model of coarse-grained locking provides
+good scaling on small numbers of processors.</p><fig id="GUID-D70A45BC-E281-403E-9D7F-519D990F0DAE">
+<title>Coarse-Grained Lock</title>
+<desc/>
+<image href="GUID-91BD4E81-4CDC-4279-8E19-5B79A63B838E_d0e638812_href.png" placement="inline"/>
+</fig><ul>
+<li><p><b>Fine-Grained Locks</b> enclose a small area of code for example
+a data structure. These locks are added to the code and the user must remember
+to release the lock. Fine locks are error prone. </p></li>
+</ul><p>As the number of processors increases, the number of locks also increases.
+The following diagram illustrates how fine locks are applied to data. In other
+words, fine locks protect individual data structures or even parts of data
+structures. All those locks add instructions and data.  To do this, we divide
+the OS into sections and divide the section into small pieces of code and
+apply lock for each piece of code. Fine-grained locking can result in near
+perfect scaling.</p><fig id="GUID-97F40770-1B6C-435B-AFF0-3BA3AC66F7DA">
+<title>Fine-Grained Lock</title>
+<image href="GUID-2E3F9FBD-21FE-4F02-B410-F756012805D2_d0e638829_href.png" placement="inline"/>
+</fig></section>
+<section id="GUID-94FDD42D-9D26-4A41-BFB6-57648083EC41"><title>Type of Locks</title><ul>
+<li><p><xref href="GUID-FB1605A8-9946-364C-A649-DEF60E1F761B.dita"><apiname>TSpinLock</apiname></xref> is the lightest weight lock available
+kernel side. If a process attempts to acquire a spinlock and one is not available,
+the process will keep trying (spinning) until it can acquire the lock. Spinlocks
+should be used to lock data in situations where the lock is not held for a
+long time.</p></li>
+</ul><ul>
+<li><p><xref href="GUID-669D0368-7ADE-35FA-881C-51D476D45B8A.dita"><apiname>RFastLock</apiname></xref> is the lightest weight lock available
+user side. There is no priority inheritance. This is a layer over a standard
+semaphore, and only calls into the kernel side if there is contention.</p></li>
+</ul><ul>
+<li><p><xref href="GUID-C0FEA3A0-7DD3-3B87-A919-CB973BC05766.dita"><apiname>RMutex</apiname></xref> is used to serialize access to a section
+of re-entrant code that cannot be executed concurrently by more than one thread.
+A mutex object allows one thread into a controlled section, forcing other
+threads which attempt to gain access to that section to wait until the first
+thread has exited from that section.</p></li>
+</ul><ul>
+<li><p><xref href="GUID-AED27A76-3645-3A04-B80D-10473D9C5A27.dita"><apiname>RSemaphore</apiname></xref> is used for Inter Process Communication
+(IPC), they are similar in performance to <codeph>RMutex</codeph>. <codeph>RSemaphore</codeph> locks
+are used when the lock must be held for a long time. These locks put the thread
+into sleep mode and are used to synchronize user contexts.</p></li>
+</ul></section>
+</conbody><related-links>
+<link href="GUID-387E98B0-568D-4DBB-9A9E-616E41E96B58.dita"><linktext>SMP - Overview</linktext>
+</link>
+<link href="GUID-FA120B3F-4EC4-5A0A-8A36-D5CD032CF1B0.dita"><linktext>Using Mutexes</linktext>
+</link>
+<link href="GUID-9D00655C-AFBA-5DF7-B11B-6B2355BDF08D.dita"><linktext>Using Semaphores</linktext>
+</link>
+</related-links></concept>
\ No newline at end of file