Chapter 3 - Processes Flashcards
Cascading termination
If a process terminates in any fashion, then all children are also terminated. Seen in Windows.
Zombie
Process that has terminated, but whose parent has not yet called the WAIT() function. Every process is a zombie at some point, but generally only for a brief moment.
Orphan
Parent process does not call WAIT() and instead terminates, leaving its child process alone.
Shared memory
Page 122. Model of interprocess communication. A region of memory that is shared by cooperating processes. Processes can read/write data to the shared region. Can be faster than message passing.
Message passing
Page 122. Model of interprocess communication. Communication occurs by means of messages exchanged between cooperating processes. Useful for exchanging smaller amounts of data because no conflicts need to be avoided. Easier to implement in a distributed system. Used for Netflix, etc.
Non-blocking
Page 126. Send a message and move along – do not wait for RECEIVE(). Part of message passing.
Blocking
Page 126. Send a message and enter the [Waiting] state until RECEIVE() occurs. Part of message passing.
[Flowchart] Message passing mechanisms
Message passing mechanisms > Direct > Symmetric
MPM > Direct > Asymmetric
MPM > Indirect > OS owns mailbox
MPM > Indirect > Process owns mailbox
Direct interprocess communication (Symmetric)
SEND(PID1, message) . . . RECEIVE(PID2, message)
Need to know each other’s PID before communication.
Direct interprocess communication (Asymmetric)
SEND(PID1, message) . . . RECEIVE(&PID2, message)
OS supplies the sender’s PID in place of &PID2.
Need to know each other’s PID before communication.
Indirect interprocess communication (OS owns)
SEND(mailbox1, message) . . . RECEIVE(mailbox1, message)
SSC may create the mailbox, but the OS can own it – OS-owned mailboxes afford greater flexibility. Many processes can read/write to this mailbox. If the process is terminated, the mailbox may persist.
Indirect interprocess communication (Process owns)
SEND(mailbox1, message) . . . RECEIVE(mailbox1, message)
If the process owns it, only the process can read from the mailbox unless it allows other processes to read from it.
Mailbox
Also called port. An object into which messages can be placed by processes and from which messages can be removed (‘received’). Each mailbox has a unique ID. Used with indirect communication.
Blocking send
“If I can’t do what I want, I’m gonna go to sleep.”
The sending process is blocked until the message is received by the receiving process or by the mailbox.
Nonblocking send
The sending process sends the message and resumes operation without waiting for message receipt.
Blocking receive
The receiver blocks until a message is available.
Nonblocking receive
The receiver retrieves either a valid method or a null.
Rendevous
Occurs between the sender and receiver when both SEND() and RECEIVE() are blocking.
Zero capacity mailbox.
Helps each process know roughly where the other process was.
Channel capacity + three types of capacity
How many unread messages may sit in a mailbox.
“Unbounded capacity” = SEND() can never block, because the mailbox can never be full. “System with automatic buffering.”
“Bounded capacity” = SEND() must block until space is available. “System with automatic buffering.”
“Zero capacity” = mailbox cannot have any messages waiting in it. SEND() must block until the recipient receives the message. “Message system with no buffering.”
Socket
Page 136.
Endpoint for communication.
Two processes communicating over a network use two sockets – one for each process. Identifiable by an IP address concatenated with a port number (146.86.5.20:1625).
Generally use client-server architecture.
Connection-oriented (TCP) sockets
Page 137.
Connectionless (UDP) sockets
Page 137.
Loopback
Page 138.
Port
Page 139.
Pipe
Page 142.
CHAPTER SUMMARY
Page 147.
Memorize this as much as possible.
Hardware context
Includes general purpose registry, etc.
