<?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>