File and IPC

Topic 7: File and IPC

Tongping Liu

University of Massachusetts Amherst 1 Midterm: 3/17 8pm-10pm

• Zoom Link (lectures link): – https://umass-amherst.zoom.us/j/91463665907 • Close book and close notes, but with one cheat sheet • Open the video but mute yourself • Ask questions verbally in a different room or over the chat • Clarify some questions over the chat

Let me know if you can’t make it for a valid reason!!

University of Massachusetts Amherst 2 Outline

• File and IO Operations • File Representations: FDT, SFT, inode table • Fork and Inheritance, Filters and Redirection • Hard vs. Symbolic Links • IPC: Pipe and Named Pipe • IPC: Shared Memory • IPC: Memory-Mapped Files

University of Massachusetts Amherst 3 Information Storing

• Applications may store information in the process’s address space. But it is a bad idea. – Size is limited to virtual address space • May not be sufficient for airline reservations, banking, etc. – The data is lost when an application terminates • Even when a computer doesn’t crash! – Multiple processes cannot share the same data

University of Massachusetts Amherst 4 Information Storing

• Criteria for long-term information storing: – Can store large amount of information – Must survive the process of creating it – Should provide concurrent accesses to multiple processes • Solution: – Store information on disks in a unit called “file” – Files are persistent, and only owner can explicitly delete it – Files are managed by the OS

• File System: controls how data is stored and retrieved.

University of Massachusetts Amherst 5 Unix File System Layout

• Files are stored on disks – Disk is divided into multiple partitions – Sector 0 of disk called Master Boot Record – End of MBR has partition table (start & end of partitions)

University of Massachusetts Amherst 6 Tracking Free Disk Space

• Two approaches to keep track of free disk blocks – Linked list or bitmap

University of Massachusetts Amherst 7 File Naming

• Motivation: abstract information stored on disk – You do not need to remember block, partition, … – Should have human readable names

• A process creates a file, and gives it a name – Other processes can access the file by that name • Naming conventions are OS dependent – Usually less than 255 characters – Digits and special characters are sometimes allowed – MS-DOS and Windows are not case sensitive, UNIX family is

University of Massachusetts Amherst 8 File Attributes

• File-specific info maintained by the OS – File size, modification date, creation time, etc. – OS dependent

• Other attributes: – Name – only information kept in human-readable form – Identifier – a unique tag (number) identifies a file within file system – Type – normal or special types – Location – pointer to file location on device – Protection – controls who can do reading, writing, executing – Time, date, and user identification – data for protection, security, and usage monitoring

University of Massachusetts Amherst 9 File Protection

• File owner/creator should be able to control: – What can be done by whom

• Types of access – Read – Write – Execute – Append – Delete

University of Massachusetts Amherst 10 Unix Example

• Mode of access: read, write, execute • Three classes of users: – Owner: – Group: – Public: RWX 7: 111

owner group public 6: 110 1: 001

chmod 761 game chmod can change file permissions

University of Massachusetts Amherst 11 I/O Related System Calls

• Five I/O system calls: – open, close, read, write , ioctl – Return -1 on error and set errno

• Use file descriptor (integer) to identify each file • 3 shared/opened file descriptors: – STDIN_FILENO (0) , STDOUT_FILENO (1), STDERR_FILENO (2)

University of Massachusetts Amherst 12 open()

#include #include int open(const char *path, int oflag); Creating a file int open(const char *path, int oflag, mode_t mode);

• Return a file descriptor (an integer) • oflag: O_RDONLY, O_WRONLY, O_RDWR, O_APPEND, O_CREAT, O_EXCL, O_NOCTTY, O_NONBLOCK, O_TRUNC;

University of Massachusetts Amherst 13 open()

• O_CREAT flag: use the 3-parameter form to specify permissions

University of Massachusetts Amherst 14 Implementation of Copying A File

University of Massachusetts Amherst 15 close()

#include int close(int fildes);

• You could close a file explicitly • Open files are closed when a program exits normally.

University of Massachusetts Amherst 16 read()

#include ssize_t read(int fildes, void *buf, size_t nbyte);

• Need to allocate a buffer to hold the bytes of read • size_t is an unsigned long type • Return value of read is a signed value – Can return fewer bytes than requested – Return value of -1 with errno set to the error – EINTR is not an error

University of Massachusetts Amherst 17 An Exmaple of read()

Read one char at a time!

University of Massachusetts Amherst 18 write()

#include ssize_t write(int fildes, void *buf, size_t nbyte);

• Not an error if return value is less than nbyte • Return value of -1 with errno set to EINTR is not usually an error

University of Massachusetts Amherst 19 An Example for write()

reads from one file and writes out to another

University of Massachusetts Amherst 20 Quiz on read()

• Suppose infile has "abcdefghijklmnop". Assuming no errors occur, what are the possible outputs of the following program?

abcd aXbZ abcZ etc.

What should we do to ensure “abcd” in the buffer?

University of Massachusetts Amherst 21 Outline

University of Massachusetts Amherst 22 File Representation

• File Descriptor Table: – An array of pointers indexed by file descriptors – Have pointers pointing to entries in System File Table • System/Open File Table: – Contains one entry for each open file – Each entry with a pointer to inode table – Other information: current file offset; count of file descriptors that are using this entry – When a file is closed, the count is decremented. The entry is freed when the count becomes 0. • In-Memory inode Table: in-use inodes

University of Massachusetts Amherst 23 inode: Store File Information

University of Massachusetts Amherst 24 File Size and Block Size

• Block size is 8K and pointers are 4 bytes – How large a file can be represented using only one single indirect pointer? – What about one double indirect pointer? – What about one triple indirect pointer?

University of Massachusetts Amherst 25 File Size and Block Size

• Block size is 8K and pointers are 4 bytes • One single indirect pointer – A block contains 2K pointers to identify file’s 2K blocks – File size = 2K * 8K = 16MB • One double indirect pointer – 2K pointers à 2K blocks, where each block contains 2K pointers to identify blocks for the file – Number of blocks of the file = 2K*2K = 4M – File size = 4M * 8K = 32 GB • One triple indirect pointer – Number of blocks of the file = 2K*2K*2K = 8 *K*K*K – File size à 64 TB ( = 2^33) ; 4B pointer à 32 TB

University of Massachusetts Amherst 26 Relationship between File Representations

Per Process

Per System

University of Massachusetts Amherst 27 What Happened for File Read/Write

1. The process passes the file descriptor to the kernel through a system call (read/write) 2. The kernel will access the entry in per-process descriptor, and get the pointer to system file table 3. For read/write, after obtaining the file offset in system file table, then it can compute the block/sector information from in-memory inode table. 4. OS will issue read. IO scheduler may combine multiple requests with the close location together. After getting, OS will get an interrupt and return from the system call. 5. For write, the OS will return when the data is putted into the buffer

University of Massachusetts Amherst 28 File Representations

Descriptor table System file table inode table [one table per process] [shared by all processes] [shared by all processes]

File A (terminal) stdin fd 0 File access stdout fd 1 File pos File size Info in stderr fd 2 stat fd 3 refcnt=1 File type ...... struct fd 4

File B (disk) File access File size File pos File type

refcnt=1 ......

System file table: dynamic information, like pos, refcnt inode table: more static, no change of inode if a file is not changed

University of Massachusetts Amherst 29 Quiz on File Representations

• If a file is opened twice in one process, how many entries will be created in file descriptor table? How many will be created in open file table? How many in inode table? • Each open() will return a file descriptor, which will has one entry in the open file table. But there is only one entry in inode table – Open file table contains dynamic information about each file, such as file offset – Inode contains static information about a file, such as blocks….

University of Massachusetts Amherst 30 Quiz on File Representations

• What about one file is opened separately by two processes? – Then we will have two entries in open file table, but only one inode entry

University of Massachusetts Amherst 31 An Example of File Representation

• Multiple entries in open file table may point to the same entry in inode table • Multiple processes may point to the same entry in open file table

What happened here?

University of Massachusetts Amherst 32 Outline

University of Massachusetts Amherst 33 Inheritance File Descriptors

• When fork creates a child – Child inherits a copy of the parent's address space, and its file descriptor table – This makes that multiple processes shares the same entry in open file table

What will happen if the child closes a file descriptor it inherits?

Closing the file descriptor in the child will close it for the child, but not for the parent, and vice versa.

University of Massachusetts Amherst 34 Preventing Leaking File Descriptors

• Not desirable for execve() system calls – Security – Child will less file descriptors • Set the close-on-exec flag (O_CLOEXEC) on all newly created file descriptors • Before invoking execve(), all file descriptors which the child process will not need will be closed. – Implement using a loop over file descriptors ranging from 3 to 255 and later 1024 https://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/ Defensive_Coding/sect-Defensive_Coding-Tasks-Descriptors-Child_Processes.html

University of Massachusetts Amherst 35 Quiz on stdin, stdout, and stderr

Whether all stdin, stdout and stderr are pointing to the same entry of system file table? • By default, it is true. Since all processes share the same ancestor, then every child will copy its file descriptor table from its parent, and these streams shall be predefined and need not be opened explicitly. • However, every process is allowed to close() or redirect any of its file descriptors, including STDIN STDOUT STDERR. Once closed they are gone and no longer exist as an FD at all.

Every Unix process has the standard file descriptors open: standard input, standard output and standard error.

University of Massachusetts Amherst 36 open() before fork()

University of Massachusetts Amherst 37 File Representations

Parent’s file descriptor table System File Table [0] STDIN [1] [2] STDOUT [3] STDERR

Child’s file descriptor table A (my.dat) [0] [1] [2] [3] both parent and child share the same system file table entry

University of Massachusetts Amherst 38 open() after fork()

University of Massachusetts Amherst 39 File Representations

Parent’s file descriptor table System File Table [0] STDIN [1] [2] STDOUT [3] STDERR

Child’s file descriptor table A (my.dat) [0] B (my.dat) [1] [2] [3] Now parent and child point to different system file table entry, with separate pos

University of Massachusetts Amherst 40 Quiz: Read Example

int main(void) { • Suppose the file my.dat contains char c = '!'; "abcdefghijklmnop” and no errors occur; char d = '!'; what will be the possible outputs? int myfd; if (fork() == -1) { Process 17514 got a return 1; Process 17514 got b } Process 17515 got a if ((myfd = open("my.dat", O_RDONLY)) == -1) { Process 17515 got b return 1; Process 17515 got a } Process 17515 got b Process 17514 got a read(myfd, &c, 1); Process 17514 got b read(myfd, &d, 1); Process 17515 got a printf("Process %ld got %c\n", (long)getpid(), c); Process 17514 got a printf("Process %ld got %c\n", (long)getpid(), d); Process 17515 got b return 0; Process 17514 got b }

University of Massachusetts Amherst 41 Quiz: Read Example 2

• Suppose the file my.dat contains int main(void) { char c = '!'; "abcdefghijklmnop” and no errors occur; char d = '!'; what will be the possible outputs? int myfd; if ((myfd = open("my.dat", O_RDONLY)) == -1) { return 1; } Process 17514 got a if (fork() == -1) { Process 17514 got b return 1; Process 17515 got c } Process 17515 got d read(myfd, &c, 1); read(myfd, &d, 1); printf("Process %ld got %c\n", (long)getpid(), c);Each character will appear once printf("Process %ld got %c\n", (long)getpid(), d); return 0; }

University of Massachusetts Amherst 42 Quiz: Read Example 3 fd = open("myinfile",O_RDONLY); Suppose myinfile is a regular fork(); file containing “wxyz”. read(fd,buf,1); Consider the following code read(fd,buf+1,1); segment and assume that it is printf("%c%c",buf[0],buf[1]); executed without errors and interrupts. Explain why “xwzy” is not possible. open() before fork: both parent and child will share the same entry in file table. That is, a character will appear ONLY once. Because each process will print two characters, then “xw” must be printed from the same process. However, it is impossible for a process to read “x” Before “w”.

University of Massachusetts Amherst 43 Redirection

• Redirection: modify the file descriptor table entry so that it points to a different entry in the system file table.

• IO redirection: tells OS to read from or written to another file, rather than the standard ones. – # ls > foo.txt How I/O redirection is implemented?

University of Massachusetts Amherst 44 Implementation of Redirection • Invoking dup2(oldfd, newfd) function – Copy descriptor table entry oldfd to entry newfd

Descriptor table Descriptor table before dup2(4,1) after dup2(4,1)

fd 0 fd 0 fd 1 a fd 1 b fd 2 fd 2 fd 3 fd 3 fd 4 b fd 4 b

University of Massachusetts Amherst 45 dup2() System Call

#include int dup2(int oldfd, int newfd);

– First close newfd silently if newfd exists – Then, copy the pointer of entry oldfd into entry newfd

University of Massachusetts Amherst 46 Another IO Redirection

• cat > my.file Redirect standard output to my.file

University of Massachusetts Amherst 47 Implementation of Last Example

• Typically, fd is closed after dup2()

University of Massachusetts Amherst 48 File Descriptor Table during Execution

After the redirection, all standard outputs will be redirected to my.file

University of Massachusetts Amherst 49 File Positions for dup2() vs. open()

• If open a file and then duplicate it to another descriptor, these two descriptors share the same file position: changing the file position of one descriptor will affect the other. • If you open a file twice even in the same program, you get two file descriptors with independent file positions.

University of Massachusetts Amherst 50 Stream IO and File Pointers

• fopen, fclose, fread, fwrite, fprintf, fscanf

• Open a file for output using file pointers

This is C++ support, not standard system calls

University of Massachusetts Amherst 51 Stream IO

University of Massachusetts Amherst 52 IO Stream

• Stream: sequence of bytes flowing in and out of the programs

University of Massachusetts Amherst 53 File Pointers and Buffering

• I/O using file pointers read/write from/to buffer, where buffer is filled or emptied when necessary with a vary size. • write may fill part of the buffer without causing any physical I/O to the file. If a write is done to standard output, and program crashes, data written may not show up on screen • Standard error is NOT buffered • Force the physical output to occur with an fflush

University of Massachusetts Amherst 54 Write to stdout

University of Massachusetts Amherst 55 Buffered Input and Ouput

University of Massachusetts Amherst 56 Fileiofork.c

#include #include int main(void) { printf("This is my output."); fork(); return 0; } This is my output.This is my output.

University of Massachusetts Amherst 57 Fileioforkline.c

#include #include int main(void) { printf("This is my output.\n"); This is my output. fork(); return 0; } The buffering of standard output is usually line buffering. This means that the buffer is flushed when it contains a newline.

University of Massachusetts Amherst 58 Directory in File System

A directory entry contains only a name and an index into a table giving information about a file à inode directory is also treated as a file

University of Massachusetts Amherst 59 Outline

University of Massachusetts Amherst 60 Links in Unix

• Link: association between a filename and an inode • Two types of links in Unix: – Hard link: creates another file with a link to the same underlying inode. – Soft/symbolic link: a link to filename in the file system • When a file is created – A new inode is assigned • Hard link – Creation : ln oldname newname – A new directory entry is created to link the filename to its inode à hard link – inode tracks the number of hard links to the inode

University of Massachusetts Amherst 61 Creating links

Hard link

Soft link

University of Massachusetts Amherst 62 Hard Links in Unix

• New hard link to an existing file – Creates a new directory entry – No other additional disk space – Increment the link count in the inode • Remove a hard link – Via rm command or unlink system call – Decrement the link count in the inode • When inode’s link count à 0 – The inode and associated disk space are freed

University of Massachusetts Amherst 63 Example: Hard Link

A directory entry, inode, and data block for a simple file

University of Massachusetts Amherst 64 Example: Hard Link

Creating command:

ln /dirA/name1 /dirB/name2

Two hard links to the same file;

University of Massachusetts Amherst 65 File Modification via Hard Links

• What would happen after the following operations:

unlink("/dirA/name1"); open("/dirA/name1"); modify the file close

After unlink, dirB/name2 is still pointing to the original inode, but dirA/name1 will create a new inode entry

University of Massachusetts Amherst 66 File Modification

The situation after modifying the file. A new file with the new inode is created;

University of Massachusetts Amherst 67 Symbolic Link

• Special file that contains the name of another file • A reference to the name of a symbolic link – OS use the name stored in the file; not the name itself. • Create a symbolic link – ln –s /dirA/name1 /dirB/name2 • Symbolic links do not affect link count in the inode • symbolic links can span filesystems (while hard links cannot)

University of Massachusetts Amherst 68 A Symbolic Link

University of Massachusetts Amherst 69 Hard vs. Symbolic Links

• Hard links – Hard links are relative to a given filesystem – References a physical file (unless the filesystem is corrupted) – A count of the hard links is kept in the inode – Removing the last hard link frees the physical file • Symbolic links – Can make a symbolic link to a file that does not exist – Even if it did exist once, a symbolic link might not reference anything – Removing a symbolic link cannot free a physical file

University of Massachusetts Amherst 70 Outline

University of Massachusetts Amherst 71 How Processes Communicate?

• The openfork example Parent’s file descriptor table System File Table [0] STDIN myfd = open("my.dat", O_RDONLY); [1] fork(); [2] STDOUT read(myfd, &c, 1); [3] STDERR

Child’s file descriptor table A (my.dat) [0] What are the problems? [1] [2] 1. Keep expanding (overhead) [3] 2. Slow 3. Can’t write at the same time Communicate via a shared file

University of Massachusetts Amherst 72 Interprocess Communication (IPC)

• IPC is to exchange data among processes • Reasons for cooperating processes: – Information sharing – Computation speedup – Modularity – Convenience

• Cooperating processes need interprocess communication (IPC)

University of Massachusetts Amherst 73 IPC: Pipe

• Create a pipe: #include int pipe(int fildes[2]); – Create a unidirectional communication buffer with two file descriptors: fildes[0] for read and fildes[1] for write – Data write and read on a first-in-first-out basis – Not external or permanent name, and can only be accessed through two file descriptors – The pipe can only be used by the process that created it and its descendants (i.e., child & grand-child processes)

University of Massachusetts Amherst 74 IPC: Pipe

University of Massachusetts Amherst 75 Ordinary Pipes

University of Massachusetts Amherst 76 Read and Write of Pipe

• Read – Not necessarily atomic: may read less bytes – Blocking: if no data, but write descriptor still opens – If empty, and all file descriptors for the write end are closed à read sees end-of-file and returns 0 • Write – Atomic for at most PIPE_BUF bytes (512, 4K, or 64K) – Blocking: if buffer is full, and read file descriptors open – When all file descriptors referring to the read end of a pipe are closed à cause a SIGPIPE signal for the calling process

University of Massachusetts Amherst 77 Pipe Write Example

Which process write? Which process read? Which process write/read first?

University of Massachusetts Amherst 78 Parent/Child File Descriptor Tables

[1] [0] [2]

Parent

[3] [4]

Pipe

University of Massachusetts Amherst 79 Pipe Write Example

Which process write? Which process read? Which process write/read first?

University of Massachusetts Amherst 80 Parent/Child File Descriptor Tables

Parent and child can communicate via pipe

University of Massachusetts Amherst 81 Pipes and Redirection ls -l | sort -n +4

University of Massachusetts Amherst 82 After Two dup2() Functions

University of Massachusetts Amherst 83 After Close File Descriptors

University of Massachusetts Amherst 84 Processes via a Unidirectional Ring

• A ring of 5 nodes – Nodes represent processes – Links represent a unidirectional pipe • How do these processes communicate ? – Message with target PID – Receive targeted message – Forward other messages

University of Massachusetts Amherst 85 Ring within A Single Process

• Code section for a single process ring without error check

int fd[2]; pipe(fd); One pipe(), dup2(fd[0], STDIN_FILENO); followed by two dup2() dup2(fd[1], STDOUT_FILENO); and two close() close(fd[0]); close(fd[1]);

University of Massachusetts Amherst 86 Ring within A Single Process

• Status after pipe(fd)

University of Massachusetts Amherst 87 Ring within A Single Process

• Status after two dup2(…, …)

University of Massachusetts Amherst 88 Ring within A Single Process

• Status after both close(…)

Standard output will be fed into standard input

University of Massachusetts Amherst 89 Results of A Single Process Ring

• What will be the output of the following code? – Write first, then read

It prints out {0,1,…,9} on the screen!

University of Massachusetts Amherst 90 Results of A Single Process Ring

• What will be the outputs of the following code? – Read first, then write

The program hangs on the first read Read from the pipe is blocked on the input. No input then no progress

University of Massachusetts Amherst 91 A Ring of Two Processes

• Code section without error check

Two pipe(), Four dup2() Four close() One fork()

University of Massachusetts Amherst 92 A Ring of Two Processes

• Status after the 2nd pipe ()

University of Massachusetts Amherst 93 A Ring of Two Processes

• Status after fork()

94 University of Massachusetts Amherst 94 A Ring of Two Processes

• After dup2()

University of Massachusetts Amherst 95 A Ring of Two Processes

• After close()

96 University of Massachusetts Amherst 96 A Ring of n Processes

Parent process break; child process create the next pipe and new process;

97 University of Massachusetts Amherst 97 Problems of Pipe

• Pros – simple – flexible – efficient communication • Cons: – no way to open an already-existing pipe. This makes it impossible for two arbitrary processes to share the same pipe, unless the pipe was created by a common ancestor process.

University of Massachusetts Amherst 98 Named Pipes

• Named pipes are more powerful than ordinary pipes

• Communication is bidirectional – The same fd can be utilized for both read and write

• No parent-child/sibling relationship is necessary between communicating processes

• Provided on both UNIX and Windows systems

University of Massachusetts Amherst 99 Named Pipes (FIFO)

• Named pipes allow two unrelated processes to communicate with each other • They are also known as FIFOs (first-in, first-out)

University of Massachusetts Amherst 100 Named Pipes (FIFO)

• How does it work? – Uses an access point (a file on the file system) – Two unrelated processes opens this file to communicate – One process writes and the other reads, thus it is a half-duplex communication

File System reads writes Process 2 Named Pipe (FIFO) Process 1

file

University of Massachusetts Amherst 101 Named Pipes (FIFO)

• Create a FIFO #include int mkfifo(const char *path, mode_t mode); • *path specific to the named pipe, which appears in the same directory as ordinary file • Can be accessed by all processes • Should be opened before read/write operations • Removing a FIFO: same as removing a file A named pipe is a special file that has no contents on the file system.

University of Massachusetts Amherst 102 Parent/Child Processes with a FIFO

Only the name of the FIFO is passed to the parent and child routines.

University of Massachusetts Amherst 103 Parent/Child Processes with a FIFO

University of Massachusetts Amherst 104 Parent/Child Processes with a FIFO

University of Massachusetts Amherst 105 Using FIFO in Client-Server Model

• Client-Server Communication – Clients request service from a server. – The server process waits for requests from clients. • A process can act as both a client and a server

• When processes are exchanging data via the FIFO, the kernel passes all data internally without writing it to the file system. Thus, it is much faster than sockets, due to not using network resources.

University of Massachusetts Amherst 106 Server: Receive and Output

Server process that creates a FIFO and open it. Whatever received from the FIFO will be write to standard output.

University of Massachusetts Amherst 107 Client: Write to a Named FIFO

Program 6.8 on page 198 [USP]

Can server and client on two different machines?

client process opens the FIFO and writes the string to the pipe.

University of Massachusetts Amherst 108 Benefits of Named Pipes (FIFO)

• Named pipes are very simple to use. • No synchronization is needed when using named pipes. • Write to a FIFO is guaranteed to be atomic as far as the size is less than 4K. • Named pipes have permissions (read and write) associated with them, unlike anonymous pipes.

University of Massachusetts Amherst 109 Limitations of Named Pipes

• Named pipes can only be used for communication among processes on the same host machine. • Named pipes can be created only in the local file system of the host, (i.e. cannot create on the NFS file system) • Careful programming is required for the client and server, in order to avoid deadlocks. • Named pipe data is a byte stream.

University of Massachusetts Amherst 110 Outline

University of Massachusetts Amherst 111 IPC: Shared Memory

• Creating a Shared Memory Segment – Allocated in byte amounts • Shared Memory Operations – Create – Attach – Detach • Shared Memory Control – Remove

University of Massachusetts Amherst 112 shmget() System Call

• Create a shared memory segment. int shmget (key_t key, int size, int shmflg); Returns: Success: unique shared memory identifier. Failure: -1 ; • key_t key: key for creating or accessing shared memory • int size: size in bytes of shared memory segment to create. Use 0 for accessing an existing segment. – int shmflg: segment creation condition and access permission. – Creating: IPC_CREAT and permissions

University of Massachusetts Amherst 113 Shared Memory Limits

Shared Memory Segment Defaults Value

Maximum segment size 1,048,576 bytes

Minimum segment size 1 byte

System wide maximum number of segments 100

Maximum number of segments per process 6? that can be attached

University of Massachusetts Amherst 114 Shmat() System Call

Attach (map) the shared memory segment into the calling process’s data segment. The pointer returned is to the first byte of the segment

Command: void *shmat ( int shmid, void *shmaddr, int shmflg); Returns: – Success: reference to the shared memory; – Failure:-1; Sets errno: Yes. Arguments: – int shmid: a valid shared memory identifier. – void *shmaddr: allows the calling process some flexibility in assigning the location of the shared memory. – int shmflg: access permissions and attachment conditions.

University of Massachusetts Amherst 115 Notes on shmat() arguments

• shmid is as before • 2nd and 3rd arguments can be used to attach to a specific address within shmem, but it is an absolute address, requiring knowledge of the address of the shared memory segment • Almost always, 2nd and 3rd arguments are 0

University of Massachusetts Amherst 116 shmdt() System Call Detach the calling process’s data segment from the shared memory segment. Command: int shmdt (void * shmaddr); Returns: Success: 0; Failure: -1; Sets errno: Yes. Argument: – void *shmaddr: a reference to an attached memory segment (the shared memory pointer).

University of Massachusetts Amherst 117 shmctl() : Shared Memory Control shmctl permits the user to perform a number of generalized control operations on an existing shared memory segment and on the system shared memory data structure. Command: int shmctl(int shmid, int cmd, struct shmid_ds * buf); Return: Success: 0; Failure: -1; Sets errno: Yes. Arguments – int shmid: a valid shared memory segment identifier. – int cmd: the operation shmctl is t perform. – struct shmid_ds * buf: a reference to the shmid_ds structure

University of Massachusetts Amherst 118 Shared Memory Data Structure

/* One shmid data structure for each shared memory segment in the system. */ struct shmid_ds { struct ipc_perm shm_perm; /* operation perms */ int shm_segsz; /* size of segment (bytes) */ time_t shm_atime; /* last attach time */ time_t shm_dtime; /* last detach time */ time_t shm_ctime; /* last change time */ unsigned short shm_cpid; /* pid of creator */ unsigned short shm_lpid; /* pid of last operator */ short shm_nattch; /* no. of current attaches */ /* the following are private */ unsigned short shm_npages; /* size of segment (pages) */ unsigned long *shm_pages; /* array of ptrs to frames */ struct vm_area_struct *attaches; /* descriptors for attaches */ };

University of Massachusetts Amherst 119 Operations of shmctl()

• IPC_STAT: Return the current value of the shmid_ds structure for the shared memory segment indicated by the shmid value. • IPC_SET: Modify a limited number of members in the permission structure found within the shmid_ds structure. • IPC_RMID: Remove the system data structure for the referenced shared memory identifier (shmid). Once all references to the shared memory segment are eliminated, the system will remove the actual shared memory segment. • SHM_LOCK: Lock, in memory, the shared memory segment referenced by the shmid argument. Superuser access required • SHM_UNLOCK: Unlock the shared memory segment referenced by the shmid argument. Superuser access required

University of Massachusetts Amherst 120 Shared Memory Related Commands

• ipcrm to delete a shared memory segment • ipcs to list shared memory segments • ipcmk to create a segment, e.g., ipcmk -M 12345

University of Massachusetts Amherst 121 Shared Memory Example

#define SHMSZ 27 #define SHMSZ 27 main() { main() { int shmid; int shmid; key_t key = 5678; key_t key = 5678; char *shm, *s; char *shm, *s; if ((shmid = shmget(key, SHMSZ, if ((shmid = shmget(key, SHMSZ, 0666)) IPC_CREAT | 0666)) < 0) { < 0) { perror("shmget"); exit(1); } perror("shmget"); exit(1); } if ((shm = shmat(shmid, NULL, 0)) == if ((shm = shmat(shmid, NULL, 0)) == (char *) -1) { perror("shmat"); exit(1); } (char *) -1) { perror("shmat"); exit(1); } s = shm; for (s = shm; *s != NULL; s++) for (char c = 'a'; c <= 'z'; c++) putchar(*s); putchar('\n’); *s++ = c; *shm = '*’; *s = NULL; } while (*shm != '*') sleep(1); } Writer Reader

University of Massachusetts Amherst 122 Outline

University of Massachusetts Amherst 123 IPC: Memory-Mapped Files

• Another IPC mechanism • Multiple processes can map the same file into their address spaces – Using mmap() system calls – mmap() requires a file descriptor as its first parameter, so the file should be opened first – mmap() only works on lseek-able true files, not pipes or sockets – When it is done, should unmap the file from the memory

University of Massachusetts Amherst 124 mmap() System Calls

• void *mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset); • Causes the pages starting at addr and continuing for at most len bytes to be mapped from the object described by fd, starting at byte offset offset. • addr can be specified (MAP_FIXED) or not • prot can be readable, writable, executable, or none • flags can be anonymous/file-backed, shared, fixed…..

Designed to replace IO system calls, while IPC is just a by-product

University of Massachusetts Amherst 125 R/W vs. Mapped Files

• Similarities: – The file is actually loaded into the disk cache before reads or writes, and writes are first performed directly on pages in the disk cache rather than on the hard disk – OS will synchronize the disk cache with disk eventually, but can be forced to sync via fsync() • Difference: – Mmap allows to directly access the physical memory stored in the page cache without system calls, but requires to create many new page tables and leads to additional (minor) page faults upon first-time access of a file page – read, on the other hand, must first load data from disk to the page cache, and then copy the data from the page cache to a user- space buffer

University of Massachusetts Amherst 126 Advantages of Mapped Files

• Simplified coding - the data is immediately available, and good for random access • Sharing - data can be shared across processes easily • Lower memory pressure - when memory is tight, data from the disk cache can be dropped or stored back to disk (clean pages don't need), while normal files need to store those pages (even clean ones) in swap space

University of Massachusetts Amherst 127 Disadvantages of Mapped Files

• An obvious disadvantage to memory mapped files is on a 32-bit OS - you can easily run out of address space. • For sequential processing, memory mapped files are not necessarily faster than standard 'stream-based' approaches of read, fscanf, etc. due to minor page faults • But it is certainly faster if the content is in disk cache of the OS.

University of Massachusetts Amherst 128 Mapped Files vs. Shared Memory

• Shmget() is the old System V shared memory model and has the widest support – Have a clunky interface (key etc), and rely on separate utility programs (e.g. ipcs) to control it – The OS has a table with entries that describe all instances, and each table entry contains a numeric key. "get" is to create a new entry or to retrieve an existing one, where the OS searches the proper table for an entry named by the key. Has a permissions structure, and a set of read- write-execute permissions for user, group, etc. (the same as with the file permissions modes) • mmap() is the new POSIX way to do shared memory and is easier to use. Prefer method. – If you try to communicate between the parent and the child, mmap() with MAP_ANONYMOUS | MAP_SHARED is by far the easiest way (and the fastest)

University of Massachusetts Amherst 129 How to Implement Mapped Files?

• That relates to the mapping between virtual and physical address

• We will talk about in next topic – memory management

University of Massachusetts Amherst 130 Outline

University of Massachusetts Amherst 131