Shared Memory

From COMP15212 Wiki
On path: IPC 1: Processes • 2: Interprocess Communication • 3: Shared Memory • 4: Files • 5: Unix Signals • 6: Pipes • 7: Sockets • 8: Synchronisation • 9: Synchronisation Barrier • 10: Atomicity • 11: Mutual exclusion • 12: Signal and Wait
Depends on MemoryProcesses

As the title implies, shared memory is a scheme where some physical memory ‘belongs’ to more than one process. This (of course) requires O.S. connivance in any system with memory mapping and protection.

The sharing of physical memory does not necessarily mean that it appears at the same virtual address.

Shared Memory

If present it can be used for various purposes. Such as …

Interprocess communication

With most multiprocessing systems a programmer can specify a block of shared memory and link more than one process to this.

There is a practical exercise covering this.

This may be done, for example, when one process is intending to create ‘daughter’ processes and communicate with them with shared variables. It is particularly useful where there is a large, simple data set to share – for example a graphical image represented as pixels.

If two (or more) processes have access to an area of RAM they can use it to exchange data. There would need to be some software protocol enforced to ensure that only valid data are read and data are not overwritten until they are no longer needed.

One possible example is a queue although many other mechanisms may be used.

Shared libraries

Rather than duplicate commonly used code it is not unusual, these days, to keep one copy of frequently used library routines and share them with any process which needs them. This may be done automatically by some operating systems.

A similar approach can be used for any read only data – although shared code will need private copies of any variables which it uses.

You may like to reflect on this principle within applications too – for example when you create many instances of a particular object running on the ‘Java Virtual Machine’ application. In this case the code may be shared by instances – and, possibly, different threads – but there may be no need for O.S. support since the sharing is within the same process.

A library will typically be run with the permissions and resources of the calling process: it must therefore be trusted as it provides a potential security hole.


Also refer to: Operating System Concepts, 10th Edition: Chapter 2.3.3.5, 3.5, 3.7.1, pages 73, 125-127, 132-136