<?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-9D93F895-B975-4F2D-A2A3-817033EA5C12" xml:lang="en"><title> Data

Integrity and Memory Barriers</title><shortdesc>This topic explains how memory barriers are used to maintain data

integrity in a multi-CPU system with shared memory and I/O.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<section id="GUID-8A6A93C2-AA57-4ABB-A6E0-64F34D12E05C"><title>Introduction</title><p>When

a thread is executed on a single CPU system, there is an order to the read/write

operations to shared memory and I/O. Since read and write operations cannot

occur at the same time, the integrity of the data is maintained.</p><fig id="GUID-86081A73-848E-49A4-A663-77D681DC6784">

<title>Shared Memory and I/O on a Single CPU System.</title>

</fig><p>Figure 1 shows how shared memory and I/O is handled on a single CPU

system. The CPU switches between threads (this is called a context switch).

Because only one thread can be executed at once, read and write operations

to shared memory and I/O cannot occur at the same time. Hence the integrity

of the data can be maintained.</p><fig id="GUID-38C5602A-15EF-4162-962B-932B13CC8377">

<title>Shared Memory and I/O on a Multi CPU System.</title>

</fig><p>Figure 2 shows how shared memory and I/O is handled on a multi CPU

system. In this system, it is possible that the read/write order will not

be the one expected. This is due performance decisions made by the hardware

used to interface memory to the rest of the system. Without some form of synchronisation

mechanism in place, data corruption will occur.</p><p>To safeguard the integrity

of data, a new synchronisation method known as a memory barrier has been implemented.</p> 

   </section>

<section id="GUID-1512CFA2-E4F7-4B02-90B3-A02BC560B821"><title>Memory Barriers</title><p>Memory

barriers are used to enforce the order of memory access. They are also known

as membar, memory fence or a fence instruction.</p><p>An example of their

use is :</p><codeblock xml:space="preserve">thread 1: 

	a = 1;

	b = 1;

thread 2: 

	while (b != 1);

	assert(a==1);

</codeblock><p>In the above code on a single-core system, the condition in

the assert statement would always be true, because the order of read/write

operations can be guaranteed.</p><p>However on a multi-core system where the

read/write operations cannot be guaranteed, a synchronization method has to

be implemented that allows the contents of the shared memory to by synchronized

across the whole system. This synchronisation method is the memory barrier.</p><p>With

the above example, the memory barrier implementation would be :</p><codeblock xml:space="preserve">thread 1: 

	a = 1;

	memory_barrier;

	b = 1;

thread 2: 

	while (b != 1);

	memory_barrier;

	assert(a==1);

</codeblock><p>In the above example, the first memory barrier makes sure that

the variables a and b are written to in the specified order. The second memory

barrier makes sure that the read operations are done in the correct order

(the value of variable b is read before the value of variable a).</p><p> Two

forms of memory barrier are supported by the Symbian platform:</p><ul>

<li><p>One that will only allow any subsequent memory access if all the previous

memory access operations have been observed.</p><p> This memory barrier does

not guarantee the order of completion of the memory requests.</p><p> This

equates to the ARM DMB (Data Memory Barrier) instruction.</p><p> This is implemented

via the<codeph> __e32_memory_barrier()</codeph> function.</p></li>

<li><p>One that ensures that all previous memory and I/O access operations

are complete before any new access instructions can be executed.</p><p> This

equates to the ARM DSB (Data Synchronisation Barrier) instruction. The difference

between this form of memory barrier and the previous one, is that all of the

cache operations will have been completed before the memory barrier instruction

completes and that no instruction can be executed until the memory barrier

instruction has been completed.</p><p>This is implemented via the <codeph>___e32_io_completion_barrier()</codeph> function.</p></li>

</ul><p>Memory barriers are used in implementing lockless algorithms, which

perform shared memory operations without using locks. They are used in areas

where performance is a prime requirement.</p><p>It is unlikely that memory

barriers would be used by anyone other than device drivers (especially the <codeph>__e32_io_completion_barrier()</codeph> function).

It is also unlikely that these functions would be used on their own. Instead

they are most likely to be called via one of the atomic operation functions.

An example of their use is :</p><codeblock xml:space="preserve">         /* Make sure change to iTail is not observed before the trace data reads which preceded the call to this function. */

         __e32_memory_barrier();

         buffer->iTail += iLastGetDataSize;

</codeblock></section>

</conbody><related-links>

<link href="GUID-387E98B0-568D-4DBB-9A9E-616E41E96B58.dita"><linktext>SMP - Overview</linktext>

</link>

</related-links></concept>