GB2420642A

GB2420642A - Sharing a block of memory between processes on a portable electronic device

Info

Publication number: GB2420642A
Application number: GB0426184A
Authority: GB
Inventors: William Allan Clark
Original assignee: Sendo International Ltd
Current assignee: Sendo International Ltd
Priority date: 2004-11-30
Filing date: 2004-11-30
Publication date: 2006-05-31
Anticipated expiration: 2024-11-30
Also published as: GB0426184D0; GB2420642B

Abstract

Process 305 creates and names a block of shared memory 314 in memory 300. This block is mapped onto process 305's virtual address space 330 at a random address 370. The MMU stores a mapping adjustment 325. Process 305 creates a pointer and stores it in shared memory 315 which includes virtual address 370. Process 310 wishing to access a specific data address in shared memory 315 maps the block of shared memory into its own virtual space 340 at address 375. To make use of a pointer stored by process 305, it must first correct the pointer by adding or subtracting the difference between its offset value 375 (as maintained by the MMU) and that value 370 of process 305 calculated with respect to some baseline 360. When memory is always allocated in pages (e.g. 4096 bytes), such as in the Symbian (r.t.m.) operating system, as an alternative to the above method the pointers may be corrected by creating a certain number of the most significant bits of an address, as a number of the least significant bits will be the same for each local address space. This is because the data will always be in the same position relative to the nearest page boundary.

Description

- - 2420642

MEMORY MANAGEMENT FOR PORTABLE ELECTRONIC DEVICE

Field of the Invention

The present invention relates to a portable electronic device with both hardware and Operating System (OS) memory management support for application software, and a method for improving device resource usage. The invention is applicable to, but not limited to, improving the performance and usability of a wireless communication device such as a mobile phone.

Background of the Invention

: 15 Complex portable electronic devices such as wireless communication devices, are commonly designed around a * S. S specific family of microprocessors and/or DSPs (Digital Signal Processors), and usually include an Operating System (OS). The OS provides a software/firmware designer with defined interfaces to many basic hardware functions of the device, and also provides some data * management functions, such as a file system. These OS features can be thought of as providing a hardware abstraction layer and a function library, which allow the software designer to work at a higher level of abstraction using more efficient languages, such as Java and C++.

The software running on the device can be divided into multiple applications or processes running concurrently on the hardware of the device, with perhaps multiple threads running within each process. Each thread will perform a task, which will probably require access to the physical memory of the device.

In many cases multiple processes will require access to the same data, requiring that this data somehow be made available to all of the processes. In general, the operating system will have access to a memory management unit (MMU) that handles the task of allocating physical memory to the processes. The MMU allocates memory to requesting software processes in contiguous blocks called pages, each page having a fixed size of, say 4Kbytes (4096 bytes) (blocks of memory in the Symbian(TM) OS are called "Chunks") . Every software application or process running on the device typically will have its address : 15 space, visible only to that application or process. S... *a.. * .

When a process requires memory, it requests it from the *..: MMU, which, in general, allocates memory in blocks or so- called "pages". The MMU reserves and allocates pages in physical memory for the requesting process, and maps them to the process's local address space. In this context, *SS...

* mapping encompasses the provision of tables of associations between physical and virtual addresses.

The local address space may, in fact, be much larger than the actual physical memory and, more importantly, the address of the mapped memory in the local address space will not, in general, correspond to the actual address of the reserved memory within the physical memory.

When the process tries to read/write to the memory, it uses addresses in the local address space. These are then converted by the MMU, for example by way of a conversion table, to the actual address within the physical memory.

In general, each process has its own local address space, and it is not possible for other processes to "see" (or access) the local address spaces of other processes.

Thus, where there are many processes that require the same data, each process must reserve an area of physical memory, and load that data into the physical memory.

Consequently, if there are, say, ten processes all requiring the same data, then that data would be loaded into the physical memory ten times. This is clearly not an efficient use of physical memory. *SSI

: 15 Furthermore, there is a time overhead in loading data SI..

into memory. Thus, loading the same data into physical memory ten times is also inefficient.

To overcome this problem, it is known to use shared memory. Shared memory is where one process reserves an area of memory, provides that area of memory with a name, and requests the MMU to make that area of memory a shared' area of memory.

Then, any subsequent processes that require the same data that the initial process has loaded into the shared memory can map it into its own local address space.

Thus, although there is only a single instance of the data in physical memory, it can be accessed by each process that requires the data.

In this way, the data is only required to be loaded into physical memory once, significantly improving efficiency in terms of both time and memory. This process relies entirely on functionality provided by the OS & MMU, which must ensure that each block of memory appears exactly the same to each process. That is, the MMU must ensure that the virtual addresses in the address spaces of multiple processes, which correspond to the physical memory addresses of the shared memory, are the same for all processes. If the MMU does not provide this functionality, then two processes will not be able to correctly share data that is located by pointers within the block of shared memory. Thus, a process trying to use a pointer, created by a different process that stored 15 it within a block of shared memory, will in all *.6.

likelihood read incorrect or non-existent data. * I **I.

SymbianTM, provide an OS commonly found in wireless communication devices. The Symbian OS supports shared * 20 memory and will allow a process to declare a block of II..

* memory as shared, and to name that memory. For this I.e...

* Symbian supports "create and name" commands, thus allowing another process to access it. However, the MNU does not guarantee that a block of shared memory will appear at the same virtual address in each process requesting access to it. This limits significantly the usefulness of the shared memory feature, as any virtual pointers in shared memory will be incorrectly interpreted by the MMU when used by a process other than that process that created the pointers.

It is known in the art to circumvent this problem by use of a "Client/Server" construct to implement shared memory. In this case, the server process manages a shared data structure for multiple "client" applications.

This solution is cumbersome both in terms of memory usage, and microprocessor time. It involves context switching between processes and creation of multiple copies of the data. In a single processor, the processor cannot perform two tasks at once. Therefore, to provide an illusion of concurrent processes being performed, the processor must switch between the active task and the to-be-active' task. This process is termed context switching'. This is, in general, unacceptable for resource-constrained systems such as portable communications devices.

*:** 15 Thus, a need exists for a method and means of allowing S...

efficient access by multiple processes to data stored in *.S.

a shared memory and referenced by pointers stored in that shared memory, while at the same time alleviating the problems associated with the priorart.

I * S

Statement of Invention

S..... * .

In accordance with a first aspect of the present invention, there is provided a method, as claimed in Claim 1.

In accordance with a second aspect of the present invention, there is provided a method, as claimed in Claim 2.

In accordance with a third aspect of the present invention, there is provided a method, as claimed in Claim 5.

In accordance with a fourth aspect of the present invention, there is provided a device, as claimed in Claim 9.

Further aspects and advantageous features of the present invention are as described in the appended Claims.

A method according to the teachings of the current invention is described for creating a block of shared memory within the physical memory of a computing device, such that a software process (B), executing on a/the processing function of a portable electronic device, preferably a wireless communications device, is able to locate and access data stored in that block of shared real memory. This shared memory having been created and named, or otherwise identified, and made generally available to other processes by a different process (A) Data stored within this block of shared memory may be referenced via one or more data pointers generated by process (A) and stored by this process in the block of V.....

* shared memory.

Advantageously, process (A) also stores within the block of shared memory, the virtual-address, or a reference to the virtual-address, at which it sees the block of shared real memory within its virtual address space. That is, process (A) stores the virtual address or reference thereto, to which the memory was mapped by the MMU, into a memory location within the shared memory. This ensures that each block of shared memory stores a value of its own absolute virtual-address in the creating process.

This value is otherwise not available to any process other than the creating process, and provides a reference point for other processes trying to locate data using pointers from within the block.

A further software process, executing on a/the processing function of the portable electronic device, wishing to access data stored in a block of shared memory, does so by requesting the block of shared memory to be mapped into its own virtual memory space. To locate and access data stored in this block of shared real memory, the process must read the virtual-address value associated with the block from out of the memory (where it was stored by the creating process), the virtual address value being preferably stored at the start of the block, i.e. it is preferably the first data value located within the block and can thus be read directly without requiring the use of a pointer. * S I * *5

Notably, the process then reads the virtual address value where it sees the block of memory within its own address- space. The process can now, advantageously and according S....' * to the teachings of the present invention, use the difference between the two virtual-address values to offset, and thus correct, all pointers to further memory addresses that are stored within the memory.

The shared memory, thus created, may advantageously be used to store both data and pointers to further data or data structures within the shared block of physical memory of the device. These further data structures could be, for example, "Themes" for a wireless communication device, or other complex data that, without the use of shared pointers enabled by the teachings of the current invention, could not be accessed in a single place by multiple processes.

In a further advantageous embodiment of the current invention, allocation of shared memory by the MMU is done in blocks called pages, whereby each requested block is exactly one page in size. Furthermore, each page contains the same number of bytes, and is preferably an integer power of 2' in size. This significantly simplifies the process of locating data within the block, as each process knows implicitly that a block of shared memory has a known fixed size of 1' page. Furthermore each application does not have to request or determine this information. : 15

A process requiring data whose location in physical memory is given by a pointer stored within a fixed size page of shared memory can, if necessary, correct the address pointed to by the pointer, simply and advantageously, by means of a method described in the teachings of the current invention. The process replaces U.....

* that number of most significant bits (MSBs) of a stored pointer address that define the location of the memory within the virtual memory of the creating process, with the corresponding number of MSBs that define the start of a page location within its virtual memory space. The remaining least significant bits (LSB5) then correctly point to the location of the data with respect to the start of the shared page, or the shared page boundary.

In a further advantageous embodiment, the data stored in the memory block includes, at least, an offset address value, an array of pointers, and an array size value.

Thus, a process accessing this block of shared memory can efficiently determine the size of the data structure within the shared memory and locate pointers to specific data structures, such as a range of phone Themes, in physical memory. The offset address is, in a further advantageous embodiment, stored in a fixed position within the block of shared memory, preferably the first memory location. In this manner, it is always the first value read from the block. This allows processes accessing the block of memory to locate the offset value without the use of a pointer, as the memory location pointed to by the pointer would itself require correction.

15 The teachings of the current invention are advantageously **..

embodied in a portable electronic device with an Operating System, preferably the Symbian Operating System, incorporating the following: a signal processing function, a memory management function, and a physical memory, thereby allowing the efficient, effective and flexible use of shared memory on the device.

*.... . * Advantageously, the teachings of the current invention can be used to significantly improve use of memory under the SymbianhM OS (an Operating System corrirnon to many wireless communication devices) running in conjunction with a MMU, by enabling complex data structures to be shared between processes without the need to resort to client/server architectures for memory sharing.

In this manner, the aforementioned problems associated with using shared memory to share data located by pointers within that memory, and specifically the use of shared memory under the Symbian OS, are resolved. This - 10 - has been achieved by storing a data value, corresponding to the virtual address of the shared memory in the virtual address space of the creating process, within the shared memory. This allows other processes to correct any pointers stored within the memory by the creating process. This ensures that the MMU locates the correct physical memory location when passed a shared pointer by a process. The teachings of the current invention are applicable to any system that includes hardware processing support for software processes that implement shared memory. The system may or may not include an OS and/or MMU.

Brief Description of the Drawings

*... 15 Exemplary embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: * * FIG. 1 illustrates a block diagram of a wireless communication unit adapted in accordance with the **... * * preferred embodiment of the present invention; FIG. 2 illustrates a flow chart of two software processes using shared memory in accordance with the preferred embodiment of the present invention; and FIG. 3 illustrates the process of mapping shared memory into virtual process memory and generating offsets in accordance with the preferred embodiment of the present invention.

- 11 -

Description of Preferred Embodiments

The preferred embodiment of the present invention will be described in terms of a mobile telephone. However, it will be appreciated that the inventive concepts may be embodied in any other type of memory resourceconstrained portable electronic device, where a number of processors share memory.

It is also envisaged that the inventive concepts of the present invention are not limited to wireless communication units, as fixed communication units, such as business/home telephone devices that connect to the public services telephone network (PSTN), car, weather station, global positioning system (GPS) device, etc. Such devices also often utilise embedded microprocessor intelligence and an operating system, and thus would benefit from an efficient method of memory sharing. * .

Referring first to FIG. 1, there is shown a simplified, functional block diagram of part of a wireless * communication unit 100, adapted to support the inventive concepts of the preferred embodiments of the present invention. The communication unit 100, in the context of the preferred embodiment of the invention is a mobile phone. As such, the mobile phone 100 contains an antenna 102, preferably coupled to a duplex filter or antenna switch 104 that provides isolation between receive and transmit chains within the mobile phone 100. The receiver chain, as known in the art, includes receiver front-end circuitry 106 (effectively providing reception, filtering and intermediate or base-band frequency conversion) . The front-end circuit is serially coupled to a signal processing function 108 which also supports a memory management unit (MNU) 128 which is advantageously modified to perform the method of the present invention, as described in greater detail with respect to FIG. 2 and FIG. 3. An output from the signal processing function 108 is provided to a suitable output device 110.

As known in the art, the receiver chain also includes received signal strength indicator (RSSI) circuitry 112, which in turn is coupled to a controller 114 for maintaining overall communication unit control. The controller 114 is also coupled to the receiver front-end circuitry 106 and the signal processing function 108 (generally realised by a digital signal processor (DSP)) : 15 The controller is also coupled to a memory device 116 that stores operating regimes, Theme data, decoding/encoding functions, and the like. A timer 118 is typically coupled to the controller 114 to control the timing of operations (transmission or reception of time- * 20 dependent signals) within the mobile phone 100. **.

I.....

* As regards the transmit chain, this essentially includes an input device 120, such as a microphone and keypad, coupled in series through transmitter/modulation circuitry 122 and a power amplifier 124 to the antenna 102. The transmitter/ modulation circuitry 122 and the power amplifier 124 are operationally responsive to the controller.

FIG. 2 illustrates a flow chart that describes a preferred embodiment of the teachings of the present invention. The two parallel processes 200 and 205 respectively represent a Server and a Client process, the - 13 memory structures 305, 310 of these processes 200, 205 are shown in FIG. 3. The Server process 200 provides or disseminates data associated with a "Theme" of the mobile phone. A Theme in this context, and in general, is a collection of data used to personalise the phone by its user. The data may be quite complex in structure and include pictures, video-images, ring-tones, wallpaper, skins or the like. The nature of the data is such that it can only be efficiently referenced by the use of pointers. The flow chart shows how the server process creates a block of shared memory and how the client server 205 accesses this block of shared memory in order to share Theme data.

: 15 Process 200, i.e. the creating process, is the Theme I...

Server, and it first creates a block of shared memory 315 S.., in step 210 and assigns a name to it. This can be performed in Symbian by using standard commands such as "create and name". The 05 and/or MMU ensure(s) that the block of shared memory 315 is mapped 335 to the virtual memory space 330 of the requesting process 200. Once the * block of shared data has been created and named 210, it also becomes available to any other process, such as the client process 205, running on the device, which can then access it by name.

Next, the process 200 loads 215 data, for example Theme data, into the block of shared memory 315. The process then publishes 220 the name of the block of shared memory 315.

For the client process 205, once it has started in step 225, it loads 230 a theme interface library that - 14 - contains, preferably, the names of all of the Themes available on the device. It then selects from the library the Theme that it requires. Having identified the required Theme, the process 205 then waits for the Theme name to be published in step 235, i.e. it waits for a block of shared memory to be created by process 200, which contains details pertinent to this Theme.

Once the Theme name has been published in step 220, the process 205 then requests that this block of shared memory 315 be mapped into its virtual address space 340, as shown in step 240.

The operating system, in this case SymbianTM, maps this shared memory 315 into the virtual address space 340 of : 15 the process 205. The process 205 cannot request that the block of memory be mapped to a specific virtual address *...

. : within its virtual memory space 340, as the SymbianlM * operating system, as it currently stands, does not * provide this functionality.

*.. 20 * . * When the OS and/or the NNU maps a block of memory, for S.....

* example the block of shared memory 315, into the virtual address space of a software process, such as the virtual address space 320 of process 200, it stores the virtual memory location of the block 370 in an address table.

This value allows the MMU to correct any local virtual address generated by the process 200, into a true physical address. As memory is mapped 335, 345 randomly into the virtual address space of a process, this offset for a block of shared memory is, in general, different for each process.

A problem would arise typically if client process 205 attempts to access a memory location within the mapped memory 345 within its virtual address space 340, by using a pointer generated by the server process 200 and stored within the shared memory 315 by that process 200. The client process 205 passes the pointer to the MMU 128, which then applies an incorrect offset to the address, i.e. the offset which it maintains for the client process 205. This results in the MMU, say MMU 128 of FIG. 1, returning incorrect data or, if the physical memory location subsequently pointed to by the now incorrect pointer value does not exist, an error.

Thus, process 205 must pre-correct required pointers 15 stored in the shared memory 315 by offsetting each pointer by the correct amount. 0***

In accordance with the preferred embodiment of the present invention, the required offset is calculated by calculating the difference between the virtual-address value 370 for the server process 200, and the virtual- * address value 375 of the client process 205. This offset is then applied 250 to each required pointer stored in shared memory 315, which were generated by server process 200. This corrects each pointer such that it will now be interpreted correctly by the MNU.

In order to better appreciate the inventive concepts described herein, FIG. 3 shows schematically the location of a mapped shared real memory block 315 accessible by two processes, process 305 and process 310. Process 305 is run, for example, by a Theme Server and process 310 a client requiring Theme data. In operation, process 305 - 16 - creates and names a block of shared memory 315 that is subsequently mapped into its virtual address space 330 at some random address 370. The MMU notes the location of the block and generates and stores a mapping adjustment value 325. Process 310 discovers the name of the block of shared memory 315 via the OS's shared memory feature, and requests that it be mapped into its local address space 340. The MMU maps the block 345 to a location 375 in the address space of the process 310. The MMU also calculates a second mapping offset 355 for this process.

When the client process 310 wishes to use a pointer created by the server process 305 to locate a specific data address, then it must first correct that pointer by *;.. 15 adding or subtracting the difference 365 between its offset value 375 (as maintained by the MMU) and that * * S. value 370 of the server process 305 calculated with respect to some baseline value 360. Advantageously, applying this correction factor 365 is equivalent to having the block of real shared memory mapped by the MMU into the same virtual memory location in each process.

S..... * .

The process of correcting the offset between the locations of the mapped shared memory in the two (or more) virtual memory spaces in applications or processes running under SymbianTM can be further optimised. Thus, memory is always reserved in physical memory, and mapped in local address spaces on 4096 byte boundaries.

Furthermore, because memory is always allocated in pages, no matter where that page of memory is mapped to in a local address space of a process, the data in the 4096 byte page will always be in the same position relative to the nearest 4096 byte boundary.

- 17 - When using 32-bit addressing, the twelve least significant bits of a 32- bit address define the 4096 byte boundary. Consequently, the twelve least significant bits of any address of any data in physical memory will be the same for that data in any local address space of any process.

Thus, in the example above, as long as the shared memory area only consists of a single page, the twelve least significant bits of the address used for the locations within the shared memory of the resources will be correct, and only the preceding twenty bits will be incorrect. I.. .

Thus according to a further preferred solution, when the I 101 shared memory only consists of a single 4096 byte page, whenever the second process needs to locate data within the shared memory based on a given address, the process can simply mask the twenty most significant bits of the local address for the mapped shared memory of the initial e w.i process. It then replaces them with the twenty most significant bits of the local address for the mapped shared memory of that process.

It is envisaged that the shared memory can be read only memory (ROM), random access memory (RAM), Flash or any other type of storage media. The shared memory may be read from and/or written to by the client process with no restrictions. The method of accessing shared data described herein is applicable to any shared memory system, and is particularly useful in devices running the SymbianTM OS which, as previously noted, supports shared - 18 - memory but does not allow a process to pre-determine to which location in its virtual memory space the shared memory will be mapped.

The teachings of the current invention can be applied to any shared memory system whereby the OS or MMU does not guarantee the location in virtual memory to which a block of physical shared memory will be mapped. It may also be used as a key feature of a shared memory system on a microprocessor system whereby no NMU and/or OS is available and shared memory is, thus, not automatically supported.

Thus, methods and apparatus for creating and accessing shared data within a shared memory, preferably in a *II( portable electronic device have been described, where the aforementioned disadvantages with prior art arrangements have been substantially alleviated.

I.'.'. * S I.e

S I

I 5b5I5

S

Claims

- 19 - Claims 1. Method for allowing a software process(B), executing on a

processing function (108) of a portable electronic device, preferably a wireless communications device (100), to locate and access data stored in a block of shared real memory (315), the method comprising the steps of: identifying or creating and naming shared memory; making the shared memory available to other processes by a different process (A) (305); and referencing said data via one or more data pointers generated by said different process (A) (305), said pointers being stored in said shared memory (315); the method characterised by the step of: S...

storing by different process (A) a virtual-address S...

(370) at which it sees said block of shared real memory (315) within its virtual address space (330), in a memory location within said shared memory (315) S..

2. Method for allowing a software process, executing S.....

* on a processing function (108) of a portable electronic device, preferably a wireless communication device (100), to locate and access data stored in a block of shared real memory (315), for example where said shared memory has been created by the method of Claim 1, the method comprising the steps of: identifying the shared memory by said process by reference to a name or other identifier; and mapping the shared memory (345) to its own virtual address space (340); __- the method characterised by the steps of: - 20 - reading by the process a virtual-address value (370) from said memory (345); reading by the process the virtual address value (375) at which it sees said memory (345) within its own address-space (340); and using a difference between the two values as an offset to correct substantially all pointers to further shared memory addresses stored within said memory (345) 3. Method according to claim 1 further characterised by the step of allocating that shared memory (315) in blocks exactly 1' page in size, whereby each page contains the same number of Bytes, preferably 4096 Bytes.

4. Method according to claim 3 further characterised in that the step of allocating shared memory in blocks I...

comprising pages of an integer power of 2' in size. I...

5. Method for allowing a software process (310) to :: 20 locate and access data stored in a block of shared real * memory (315), for example where the shared memory has S...

been created by the method of Claim 1, the method SI....

* comprising the steps of: identifying by said process (310) the shared memory by reference to its name or other identifier; and mapping the shared memory (345) to its own virtual address space (340); the method characterised by the step of: correcting, by the process (310), substantially all pointers to memory addresses stored within said memory (345) by replacing a number of most significant bits of each address that define the start of page location (370) within the virtual memory (330) of the creating process - 21 - (305), with a corresponding number of bits defining a start of page location (375) in the virtual memory space (340) of the process (310) 6. Method according to any of preceding Claims 1, 2 or 5 further characterjsed by storing data in the shared real memory (315) wherein the data comprises at least an offset address value (370), and one or more pointers to further memory locations.

7. Method according to Claim 6 further characterised by the step of identifying, by the pointers, the location(s) of theme-data, preferably themes relating to the operation of the wireless communications device such as skins, ring-tones, screen-savers and the like, located in physical memory (300) on the device. a... * * a.

8. Method according to Claim 6 or Claim 7 further characterised by the step of storing the offset address :: 20 value (370) in a specific memory location, preferably the first memory location in the block of shared memory (315) * . 9. Device (100) adapted to implement the method of any of Claims 1 to 8, wherein said device encompasses a signal processing unit (108, 200) operably coupled to a memory management unit function (128) that is operably coupled to a physical memory (116) 10. Device (100) according to Claim 9 further characterised in that the device (100) is a wireless communications device (100) running the SymbianTM Operating System on the device.

- 22 - 11. Device according to Claim 9 or Claim 10 further characterised in that the OS and/or the MMU support the creating and naming of shared memory.

12. A method for creating a data structure substantially as hereinbefore described with reference to, and/or as illustrated by, FIG. 2 or FIG. 3 of the accompanying drawings.

13. A wireless communication device substantially as herejnbefore described with reference to, and/or as illustrated by, FIG. 1 of the accompanying drawings. S... S... a... * * **S S. * * S S * S.

*....S * S * S* * * S...

S

55....

S S