ipc 1 Flashcards
1
Q
Interprocess Communication
A
- Processes may be independent or cooperating
– An independent process cannot affect or be affected by the execution of another process - A process that does not share data with another process is independent
– A cooperating process can affect or be affected by the execution of another process - A process that shares data with another process is a cooperating process
- Cooperating processes require interprocess communication (IPC)
2
Q
Why provide an environment for cooperating processes?
A
Why provide an environment for cooperating processes?
– Information sharing
* Cooperating processes can share information (such as access to the same files) among multiple processes, but a mechanism is required for parallel access
– Modularity
* Involves dividing complicated tasks into smaller subtasks, which can be completed by different cooperating processes
– Computation speedup
* Subtasks of a single task can be performed in parallel using cooperating processes
– Convenience
* Different tasks completed/managed by cooperating processes
3
Q
Methods of Cooperation
A
- Cooperation by sharing
– Use shared data such as memory, variables, files, databases, etc. mutually exclusive
– Critical section used to provide data integrity with mutually exclusive writing to prevent inconsistent data - Cooperation by communication
– Cooperation using messages (message passing)
– May lead to deadlock if each process waiting for a message from the other to perform an operation
– Starvation also possible is process never receives a message
We will focus on message passing in this class
4
Q
Message Passing
A
- A mechanism is needed for processes to communicate and synchronize their actions
- In a message system, processes communicate with each other without resorting to shared variables
- IPC facility provides two primitive operations for fixed or variable-sized message passing: send and receive
- If two processes wish to communicate, they need to
– Establish a communication link between them - Logical (e.g., logical properties) or physical (e.g., shared memory, hardware bus)
– Exchange messages via send/receive
5
Q
Synchronizing Messages
A
- Message passing may be either blocking or non-blocking
– Blocking is considered to be synchronous - Send sender blocked until message received
- Receive receiver blocks until a message is available
– Non-Blocking is considered to be asynchronous - Send sender resumes operation immediately after sending (i.e., send and continue)
- Receive receiver returns immediately with either a valid or null message
6
Q
Buffering
A
- A message queue can be implemented in one of three ways
– Zero capacity
* No messages may be queued within the link
– Requires sender to wait until receiver retrieves message
– Bounded capacity
* Link has finite number of message buffers
– If no buffers are available, then sender must wait if the link is full
– Unbounded capacity
* Link has unlimited buffer space, so sender never needs to wait
7
Q
IPC Methods
A
We will explore the following IPC methods
– Signaling
* As a limited form of IPC, a signal is essentially an asynchronous notification sent to a process in order to notify it of an event that occurred
– Files
* A file is a durable block of arbitrary information, or resource for storing information
– Pipes
* A pipe is a synchronized, interprocess byte stream
– Sockets
* Sockets provide point-to-point, two-way communication between two processes, even processes on different systems
8
Q
What Are Signals?
A
A signal is a software interrupt
– Notification of an event
* A way to communicate information to a process about the state of other processes, the OS, and hardware so that the process can take appropriate action
– Can change the flow of the program
* When a signal is delivered to a process, process will stop what it’s doing – and either handle or ignore signal
– Signals can be delivered in an unpredictable manner
* Originate outside of currently executing process
* Asynchronous events due to external trigger at the hardware or OS level – causes a context switch!
Every signal has a name that starts with SIG, a value, a default action, and a description
– See man 7 signal
9
Q
Default Action of Signals
A
Each signal has a default action
– Term the process will terminate
– Core the process will terminate and produce a core dump file that traces the process state at the time of termination
– Ign the process will ignore the signal
– Stop the process will stop, like Ctrl-Z
– Cont the process will continue from being stopped
10
Q
Flow of Signals
A
- Event gains attention of OS
- OS stops process execution immediately – Sends it a signal
- Signal Handler then executes to completion
- Process execution resumes where it left off
11
Q
Signal Events
A
In the context of terminal signaling, programs can stop, start, and terminate
– Ctrl-C is the same as sending SIGINT (2) signal
* Default handler exits process
– Ctrl-Z is the same as sending a SIGSTOP (20) signal
* Default handler suspends process
– Ctrl-\ is the same as sending a SIGQUIT (3) signal
* Default handler exits process
– Typing fg or bg at the terminal is the same as sending a SIGCONT (18) signal to bring or send a process to the foreground or background, respectively
12
Q
Signal Handling
A
Each signal type has a default handler
– Most default handlers exit the process
- A program can install its own handler for signals of almost any type
– Cannot install its own handler for the following signals - SIGKILL (9)
– Default handler exits the process
– Catchable termination signal is SIGTERM (15) - SIGSTOP (19)
– Default handler suspends the process
– Can resume the process with signal SIGCONT (18)
– Catchable suspension signal is SIGTSTP (20)
13
Q
Installing a Signal Handler
A
sighandler_t signal(int iSig, sighandler_t pfHandler);
– Installs pfHandler as the handler of signals for type iSig
– pfHandler is a function pointer
typedef void (* sighandler_t) (int);
– Returns the old handler on success; SIGERR on error
– After call, pfHandler is invoked whenever process receives a signal of type iSig
14
Q
Predefined Signal Handlers
A
- Can install predefined signal handler SIG_IGN to ignore signals
void (*pfRet)(int) = signal(SIGINT, SIG_IGN);
– Subsequently, process will ignore SIGINT (2) signals - Can install predefined signal handler SIG_DFL to restore default signal handler
void (*pfRet)(int) = signal(SIGINT, myHandler);
…
pfRet = signal(SIGINT, SIG_DFL);
– Subsequently, process will handle SIGINT (2) signals using the default handler for SIGINT (2) signals
15
Q
Sending Signals via Command
A
- kill –signal pid
– Send signal of type signal to process with ID pid
– Specify signal type name (–SIGINT) or number (–2)
– Examples:
kill –2 1234
kill –SIGINT 1234
Same as typing Ctrl-C if process 1234 is running in foreground - killall loop
– Send a signal to all processes named loop to “terminate”
– This will actually send the signal SIGTERM, whose purpose is to communicate a termination request to the given process, which does not necessarily have to terminate
16
Q
Sending Signals via System Call
A
- int raise(int iSig);
– Instructs OS to send signal of type iSig to current process
– Returns 0 to indicate success; non-0 to indicate failure
– Example:
int retVal = raise(SIGINT); // process commits suicide
assert(retVal != 0); // should not get here - int kill(pid_t iPid, int iSig);
– Sends iSig signal to process with ID iPid
– Equivalent to raise(iSig) when iPid is ID of current process
– Example:
pid_t iPid = getpid(); // process gets its pid
kill(iPid, SIGINT); // sends itself a SIGINT signal, commits suicide
17
Q
pause() Function
A
- int pause( );
– Suspends the calling process, without wasting resources, until some kind of signal is caught
– Signal action can be the execution of a signal handler function or process termination
– Only returns –1 when a signal was caught and the signal-catching function returned
18
Q
File Management
A
- A file is a collection of related information, defined by its creator
– E.g., source code, binary files, data, … - With respect to files, the OS is responsible for:
– File creation and deletion
– Directory creation and deletion
– Support of primitives for accessing and manipulating files and directories
– File security
– Mapping files onto secondary storage
– Hiding differences between storage types
19
Q
Standard Linux Files
A
- Linux views absolutely everything as files
– There are default files associated with every shell where a command reads its input from and sends its output and error messages to
– These three files known as standard files for the command - stdin standard input default = keyboard
- stdout standard output default = terminal
- stderr standard error default = terminal
File descriptor is unique, non-negative integer used to identify open files on a per-process basis
20
Q
File & Directory Permissions
A
- Linux controls the who and what access for files and directories through the use of a permission list
– Sequence of ten characters organized into four parts to the leftmost output of ls –l command - Permission list
The first column describes the type of file d directory
– ordinary file
l symbolic link
s socket
p named pipe
c character device file (e.g., terminal)
b block device file (e.g., hard disk drive)
– Most often, users see either – or d for ordinary files and directories
examples:
-rwx——
drwxr-xr-w
-rw——-
21
Q
Reminder: Basic Commands
cat
echo
type
more
less
head
tail
diff
A
- File Viewing Commands
– cat concatenate files and print to standard output (terminal)
– echo print a line of text
– type print a brief description of a command
– more file viewer for paging through text on screen at a time
– less file viewer similar to more, but with more features
– head print the first n lines of a file
– tail print the last n lines of a file
– diff compare files line-by-line
22
Q
Overview of Files
A
- Data communication with a C program and the outside world is performed through files
- Files are a non-volatile way to store data by means of such media as tape, CD-ROM, floppy disk, ZIP disk, hard drive, etc.
- C (just like the Linux operating system) considers all process communication media to be files
– An ordinary file on a disk is considered to be a file
– So is the keyboard, the screen, parallel ports, and serial ports
23
Q
Linux Files
A
- A Linux file is a sequence of m bytes
– B0, B1, …, Bk, …, Bm-1 - All I/O devices are represented as files
/dev/sda2 (/usr disk partition)
/dev/tty2 (terminal) - Even the kernel is represented as a file
/dev/kmem (kernel memory image)
/proc (kernel data structures)
/dev/ is the part in the Unix directory tree that contains all “device” files
24
Q
I/O and Data Movement
A
Input and output share common property of unidirectional movement of data and support to sequential access to data
– The flow of data into a program (input) may come from different devices such as keyboard, mouse, memory, disk, network, or another program
– The flow of data out of a program (output) may go to the screen, printer, memory, disk, network, another program
25
Some Linux File Types (Review)
* Regular file
– Binary or text file (Linux does not know the difference)
* Directory file
– A file that contains the names and locations of other files
* Character special and block special files
– Terminals (character special) and disks (block special)
* FIFO (named pipe)
– A file type used for interprocess communication to exchange data between unrelated processes
* Socket
– A file type used for network communication between processes
26
Communication through Files
* Storing and manipulating data using files is known as file processing
* Programs access files through basic file operations
– Open a file
– Read data from a file
– Write data to a file
– Close a file
* Text files store all data types as character bytes
– The way a program reads the data (either text or binary mode) determines how the data is interpreted
– Example: 12 z rti 456.79 room
27
Standard I/O Functions
Examples of standard I/O functions:
– Opening and closing files (fopen and fclose)
– Reading and writing bytes (fread and fwrite)
– Reading and writing text lines (fgets and fputs)
– Formatted reading and writing (fscanf and fprintf)
28
Standard I/O Streams
* Standard I/O models open files as streams
– Abstraction for a file descriptor and a buffer in memory.
* Three files are automatically opened each time a C program is
run and automatically closed when a C program ends:
– stdin (standard input, default source = keyboard)
– stdout (standard output, default destination = screen)
– stderr (standard error, default destination = screen)
29
Buffering in Standard I/O
* Standard I/O functions use buffered I/O
* You can see this buffering using the Linux strace program:
fflush dumps the buffer to stdout
30
File Descriptors
* Each open file is associated with an open file description
– An OS internal record of how a process or group of processes are currently accessing a file that includes
* File offset indicates byte position where next I/O operation begins
* File status indicates append mode/not, blocking/non-blocking, etc.
* File access mode indicates whether file can be read or written
* Each process has a logical array of references to open file descriptions
– Logical indices into this array are file descriptors used to identify the files for I/O operations
* A file descriptor does not describe a file – it’s just a number ephemerally associated with a particular open file description
– List open files: lsof –p
* Other descriptors are assigned by system calls to open/create files, create pipes, or bind to devices or network sockets
– E.g., pipe(), socket(), open(), creat()
* A common set of system calls operate on open file descriptors independent of their underlying types
– E.g., read(), write(), dup(), dup2(), close()
31
Files as Pipes for Data
* Files act as pipes to bring a stream of data into the program and send a stream of data out of the program
* The program reads data from stdin and writes data to stdout as if they were ordinary files
32
How is data read or written from a file?
One Byte at a Time
* Data is read or written one byte at a time from a file until the end of the file is reached or until the file is closed
* The file system uses a pointer to keep track of the next byte to read or to write
33
Functions Using stdin and stdout
* Some standard C functions implicitly use stdin and stdout
scanf("%d", &aNumber);
aSymbol = getchar();
gets(theBuffer); // High security risk
printf("Average: %5.2f", theAverage);
putchar(aCharacter);
puts(aPhrase);
* Other functions need to have stdin and stdout specified as the file descriptor
fscanf(stdin, "%d", &aNumber);
aSymbol = fgetc(stdin);
fgets(theBuffer, sizeof(theBuffer), stdin);
fprintf(stdout, "Average: %f", theAverage);
fputc(aCharacter, stdout);
fputs(aPhrase, stdout);
34
files recap
* OS has the responsibility of your files
* In the lowest level, the OS identifies files using an i-number, which when paired with a major/minor number of the physical device tells it in a unique way saying
which file stored on any disk within the entire computer system
* The combo of i-number + major/minor number is for the OS as the filename is to a human
* The idea of PATH describes to the OS how to identify a specific human name for any file in the system i.e /x/y/z
– translates to specific set of blocks on a storage device
* When each program performs the I/O the program could hand the OS the PATHNAME for specific files
* Instead it could hand a file descriptor or fd
* When a process is going to need access (R/W) to a file, it hands the OS, the PATHNAME.
* The OS translates the PATHNAME into a unsigned integer (file descriptor)
* fd is a small integer that is passed around from a user process to the kernel to easily identify what specific ‘open file’ the [processes desires to have the I/O performed
* UNIX OS calls it a fd, WINDOWS OS calls it a handle
35
What is a Pipe?
* A pipe is a simple, synchronized way of passing information between processes
– A pipe is a special file/buffer that stores a limited amount of data in a FIFO (i.e., sequential) manner
– Pipes are commonly used from within shells to connect stdout of one utility to stdin of another
* Pipes provide a basic level of synchronization
– If a process tries to write to a full pipe, it is blocked until the reader process consumes some data
– If a process tries to read from an empty pipe, it is blocked until the writer produces some data
* Data is written to and read from the pipe using the unbuffered system calls write() and read()
36
Two Types of Pipes
* Unnamed pipes
– Not associated with any file
– Can only be used with related processes, e.g a parent & child process
– Exist only as long as the using processes are not terminated and support unidirectional communication
– Created using the pipe() system call
* Named pipes, or FIFOs
– Associated with a file and can be used with unrelated processes
– Has a directory entry with file access permissions
– Can support bidirectional communication
– Created using the mknod() or mkfifo() system calls
37
Named pipe creation
To make a named pipe within a C program use include the following C libraries:
#include
#include
and to create the named pipe(FIFO) use mkfifo()function:
if (mkfifo("test_fifo", 0777)) /* permission is for all */
{
perror("mkfifo");
exit(1);
}
38
Unnamed Pipes
The pipe() system call creates an unnamed pipe and opens it for reading and writing
General syntax
int pipe(int fd[2]);
– If successful, it will return two integer file descriptors in fd[0] and fd[1]
– fd must be an integer array of size 2
– The file descriptor in fd[0] is associated with the read end of the pipe and fd[1] is associated with the write end of the pipe
– Returns -1 if an error occurred
39
Writing to a Pipe
#include
ssize_t write(int fd, const void *buf, size_t count);
* Appends up to count bytes from the end of the pipe referenced by the file descriptor from the buffer
* Atomicity guaranteed for requests w/size typically ~ 4096 bytes or less
– See PIPE_BUF in /usr/include/linux/limits.h for block size
(An operation done by a computer is considered atomic if it is guaranteed to be isolated from other operations that may be happening at the same time)
* If write() is done for a pipe not open for reading by any process,
– SIGPIPE signal is generated to signify a broken pipe with errno set to EPIPE
– SIGPIPE signal is sent to a process when it attempts to write to a pipe whose read end has closed
* See man 2 write for more information on this system call
40
Reading from a Pipe
#include
ssize_t read(int fd, void *buf, size_t count);
* Attempts to read up to count bytes from end of the pipe referenced by the file descriptor from the buffer in a FIFO manner
– Returns number of bytes read from the buffer
* If read() done for pipe not open for writing by any process, 0 is returned
* If read() done for empty pipe open for writing by another process, the process sleeps until the input becomes available
* See man 2 read for more information on this system call
41
Creating and Using Pipes
* Created using pipe():
int filedes[2];
pipe(filedes);
.
.
.
write(filedes[1], buf, count);
read(filedes[0], buf, count);
* Pipes are anonymous
– There is no name in the file system
* But then how do two processes share a pipe?
42
Unnamed Pipes
* Since access to an unnamed pipe is through the file descriptor mechanism, only the process that created the pipe and its descendants may use the pipe (e.g. only parent and child process)
* The typical sequence of opening unnamed pipes
– The parent process creates an unnamed pipe. It is crucial that this be done before forking
– The parent process forks
– The writer process closes the read end of the pipe
– The reader process closes the write end of the pipe
– The processes communicate by using write() and read()
– Each process closes its active pipe-end when finished
43
Sharing a Pipe
int filedes[2];
pipe(filedes);
pid = fork();
if (pid == 0) {
close(filedes[1]);
// child now reads
} else {
close(filedes[0]);
// parent now writes
}
* The fork() system call duplicates parent’s file descriptors
– Parent and child must close unused descriptors – necessary for correct
use of pipes
44
dup() System Call
#include
int dup(int oldfd); E.g.: int file2 = dup(file)
* Creates a copy of the oldfd file descriptor with the same open pipe, file pointer, and access mode (R/W etc) in common with the original file descriptor that is set to remain open across the exec family of system calls
* Returns the lowest unused file descriptor, -1 if error
– Problems if file descriptor returned is not one you are expecting!
* A useful system call to convert a stream to a file descriptor
int fileno(FILE *fp);
Note that dup() refers to a file descriptor, not a stream!
45
Standard file descriptors
File descriptor File
0 STDIN
1 STDOUT
2 STDERR
46
dup() Example
int fd[2];
pipe(fd);
close(fileno(stdout));
dup(fd[1]);
* Since 1 is the lowest fd available, the write end of the pipe is duplicated at fd 1 (stdout)
– Now any data written to stdout will be written to the pipe
* But you are taking a chance that the file descriptor that will be returned by dup() is what you want
– The process may be interrupted between the close() and the dup()
47
dup2() System Call
#include
int dup2(int oldfd, int newfd);
* A better alternative to dup() in that it makes the newfd file descriptor as the copy of the old file descriptor atomically, closing newfd first if necessary
– There is no time lapse between closing newfd and duplicating oldfd into its spot
* Both oldfd and newfd now refer to the same file
48
Implement Redirection
* When a process forks, the child inherits a copy of its parent's file descriptors
* When a process execs, all non-close-on-exec file descriptors remain unaffected
– This includes stdin, stdout, and stderr
* To implement redirection, the shell simply does the following
– The parent shell forks then waits for the child shell to terminate
