<?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 xml:lang="en" id="GUID-65C49B47-6C63-536E-9B31-1FFA518A63F1"><title>Shared Buffers</title><shortdesc>This topic explains the concepts of shared buffers and shared-buffer pools. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>Copying large amounts of data between memory contexts uses CPU cycles, and therefore impedes performance and battery life. Sharing memory areas avoids copies and improves efficiency. However, it also creates security and robustness risks, and must only be applied to trusted components. </p> <section><title>Shared buffer</title> <p>A buffer is a contiguous section of physical memory with defined characteristics and a known layout. </p> <p>An <xref href="GUID-BD30996A-2737-398C-85AF-3E78B79E3320.dita"><apiname>RShBuf</apiname></xref> is a shared buffer : an area of shareable memory. Processes can share the handle to an <codeph>RShBuf</codeph> object to access the data it contains. </p> </section> <section><title>Shared-buffer pool</title> <p>A pool is a collection of buffers with common characteristics. These characteristics are their size and their DMA requirements (physical memory address range). The pool preallocates the memory for the buffers and is responsible for allocating and managing the buffers within the pool. The pool is the only provider of buffers. </p> <p>An <xref href="GUID-69A28019-A2D4-3498-8205-ABE6F5F5A213.dita"><apiname>RShPool</apiname></xref> is a shared-buffer pool: it contains shared buffers of identical size. It is the only provider </p> <p>The <codeph>RShPool</codeph> grows and shrinks automatically. It allocates more memory when more shared buffers are required, and frees memory occupied by unused buffers when possible. </p> </section> <section><title>Use case</title> <p>A typical use case for shared buffers involves a group of components that execute in different processes and need to share data. Some components in the group produce data, request a shared buffer for it and send the buffer to others. Each component can read the data, add to it or write over it before passing the buffer to the next component. When the data has been processed, the buffer can be returned to the pool which then considers it available for another request. </p> <p>Components in the group are trusted to access the shared memory: they usually execute in privileged processes. Some of these components may be device drivers, therefore executing in kernel space. </p> </section> </conbody><related-links><link href="GUID-B7A6571B-564A-5299-BA2E-1BDFC463BD21.dita"><linktext>Flexible Memory Model</linktext> </link> <link href="GUID-A248C2C0-5F64-5484-85B2-57C86E3499E1.dita"><linktext>Memory
                Management in the Communications Framework</linktext> </link> </related-links></concept>