Operating Systems

SAMET YALMA 190336 SHARED MEMORY

1.What is Shared Memory?

Shared memory (SHM) is another method of interprocess communication (IPC) whereby 2 or more processes share a single chunk of memory to communicate. The shared memory system can also be used to set permissions on memory, allowing for things like malloc debuggers to be written.

2.Types of Shared memory available

Basically there are two different types of shared memory available for most flavors of UNIX. As you may have guessed, each of the two original ancestors of modern UNIX have their own implementation, although almost all modern UNIX flavors implement both. The names of the respective implementations are System V IPC, and BSD mmap.

3.General Principles
Basically using shared memory under both systems will involve the following: Uniquely naming the segment Each implementation has a method establishing a system wide unique name for each segment so that other applications may access it. Both also have methods of procuring private (or "anonymous") segments. Specifying access permissions Both implementations allow you to specify access using the traditional read/write/execute scheme. Race conditions Dealing with race conditions varies under each system.

4.BSD mmap ,,,Synopsis,,,

5.Overview Mapping Files When you request a shared segment under the BSD implementation, what you are really doing is requesting that a file of length 'length' be mapped into the address pointed to by 'start' of your process space starting 'offset' bytes into the file. If start is NULL, the address is determined by the kernel. NOTE: You MUST know the length of the file being mapped (see fstat(2)), and the length of your segment WILL NOT CHANGE from this initial length. This means if write past the end of the segment, the file will not be appened to. You will get a segmentation fault instead.

Permissions and access

The standard file modes are checked by the kernel to determine whether or not a process has access to map a file (shared or not). In addition, you may also specify permissions on the segment itself. These permissions describe to the kernel what may be done to the actual memory (Can it be executed? Can it be read? Written to?) The improtect system call can be used to change permissions on any section of previously mapped memory that starts on a page boundry.

Syncronization When you write to a your shared segment, your changes do not appear immediately to the file until you perform an msync(2). They are, of course, visible to other processes who also are sharing your segment.

6.Writing a malloc debugger Concepts So right now we know that we can map memory into our process at an address we specify, and we can also set permissions on this memory using mprotect. Furthermore, we know that mapped memory is not actually allocated by the system until it is faulted (or accessed in some way). We can use these facts to create a simple malloc debugger.

Goals

Basically we want to protect against the most common memory usuage errors using various combinations of mmap and mprotect so that when programs make these errors, they exit immediately with a SEGVinstead of continuing to produce bizzare and (seemingly) unrelated side effects. Overflows & Underflows
The most common errors in programming with dynamic memory are buffer overflows (writing past the end of an allocated segment), and underflows (writing in the memory before an allocated segment). Here we take advantage of our little friend mprotect() So, essentially all we need to do is mark a page of memory ajoining the valid allocated memory with no access permissions. However, since we can only set permissions on entire pages of memory.We can only prevent buffer overflows or underflows, but not both.

Using free'd memory A third common mistake in programming is trying to access already freed memory. We can prevent this easily enough by unmapping a free()'d region, and mapping that same address and length to anonymous memory with no permissions set. Note this shouldn't cause any memory leak, because the kernel should dispose of the unmap()'ed pages, yet should not allocate any of the new pages until the program faults them (and will subsequently seg fault anyways).

7.System V IPC Introduction System V IPC is meant to provide and entire IPC mechanism. As such, it is more heavyweight than BSD mmap, and provides three methods of communication: message queues, semaphores, and shared segments. Like BSD mmap, System V IPC uses files to identify shared segments.

Common Ground The three System V IPC mechanisms share some common ground when it comes to creation and permissions. This section will attempt to give you an overview the creation process.

Description All three IPC methods provided by the System V IPC are assocated with system-wide integers, called keys. While it is not required, these keys are traditionaly obtained via ftok(2). ftok(2) takes a filename and a project argument to generate a unique key that describes an instance of an IPC mechanism. The project argument allows you to have multiple IPC mechanisms associated with the same filename. You may also specify a key of IPC_PRIVATE that will be used only by your process and it's children.

Usage Once the segment is created and you have it's id, you must attach it, or map it into memory. This is done with shmat(2). shmat works much the same as mmap in that you can specify an address to map to, but the address must be a multiple of SHMLBA, unless you specify SHM_RND in the flags paramater. Various operations can be performed using shmctl(2) IPC_STAT can be used to fill in the struct shmid_ds structure. You can then set various fields (including changing ownership and premissions of ipc_perm) using IPC_SET. But perhaps the most important ctl operation is IPC_RMID. When all of your programs are done using a segment, you MUST shmctl it with IPC_RMID (the shmid_ds structure may be NULL), or else the segment will remain in memory forever.

Thank you for attention