3120: Process

Synchronization &
Interprocess
Communication
Agenda
• Announcements
• Lectures are being recorded
• Assignment 3 will be announced on Brightspace

• Lecture Contents
• Fixing Linked Lists
• Interprocess Communication (IPC)

• Reading: Interprocess Communication (IPC) 5.7

Recall, Per Node
Locking
Per Node Locking
• Which nodes do we need to lock when inserting or
deleting?
• The node before the insertion/deletion? YES

• The node being deleted? YES

• The node after the deletion? NO
• The node after the insertion? NO
• Why?
• Nodes being modified should be locked
• Nodes are locked in front to back order.
• To delete/insert node, the previous node is locked first
• The node after insertion/deletion will not be locked until
the preceding node is locked.
Node Locks
• Lock preceding node
• Lock node to be deleted

head next next next next

key key key key null
item item item item
1 2 3
next
key
item
Node Lock Delete(key)
delete(key) {
lock(head)
Node n = head
if (key == head->key) {
head = n->next
} else {
unlock(head)

en
for ( ; n->next != null; n = n->next) {
if (n->next->key == key) break
}

ok
lock(n)
lock(n->next)
tmp = n
n = n->next
tmp->next = n->next
unlock(tmp)
Br
}
unlock(n)
Node Lock Insert(key,
item)
insert(key, item) {
Node n = Node(key, item)
lock(head)
if(key < head->key) {
n->next = head
head = n
unlock(head)

n?
} else {
unlock(head)
for (tmp = head; tmp->next != null; tmp = tmp->next) {

ke
if(tmp->next->key >= key) break
}
lock(tmp)

ro
n->next = tmp->next
tmp->next = n
unlock(tmp)
}
What’s Broken
What’s Broken? (Insert)
• Consider two concurrent operations:
• Node 2 being deleted.
• A node being inserted between nodes 2 and 3
Insert waits
• The inserted node could be lost for lock

head next next next next

key key key key null
item item item item
1 2 3
next
key
item
What’s Broken? (Delete)
• Consider two concurrent operations:
• Node 2 being deleted.
• Node 3 being deleted.
Delete(3)
• The linked list is broken waits for lock

head next next next next

key key key key null
item item item item
1 2 3
The Basic Problem
The time between which a link is followed and a lock
is acquired leads to race conditions and destructive
interference.

head next next next next

key key key key null
item item item item
1 2 3
Solution: Hand over Hand
Locking
Need to lock the previous node to follow the link

head next next next next

key key key key null
item item item item
1 2 3
How Do We Fix It?
• Hand over hand locking of nodes as we walk the list.
• Expensive
• Lock segments of the list
• Somewhere In between one lock per node and one lock
per list.
• Somewhat restricts concurrency
• Use a deleted flag, and restart from head of list if
lock node is deleted
• Maximizes concurrency
• Susceptible to starvation
Discussion
• Getting synchronization right is hard!
• Even simple data structures like linked lists can
cause problems.
• There is inherently a trade-off between
• Complexity
• Concurrency
• Efficiency
• Each data structure and problem have their own
optimal solution
• What’s next?
Interprocess
Communication
Interprocess
Communication
• Interprocess Communication (IPC) involves
concurrent processes exchanging data among each
other
• Several common foms of IPC
• Shared Memory: processes communicate by
reading/writing shared memory
• Message Passing: processes communicate by sending
messages to each other
• Signals: processes can asynchronously notify another
process
• Pipes: special form of message passing (covered later)
Shared Memory
• Model we have been discussing so far
• General purpose IPC system
• All processes/threads run on the same machine
• All processes/threads have access to the same memory
• Analogy: A black board in a classroom
• Most common type of IPC, because
• Can be done locally
• Natural form of concurrency
• Little reliance on underlying system
• Very efficient and fast (low overhead)
Shared Memory Operation
• Operation
• Processes communicate by accessing shared memory
• Usually via reads/writes (or special atomic operations)
• All cooperating processes must have access to the same
shared memory
int counter;
char buffer[8192];
…
…
Node *head;
…
Challenges with Shared
Memory
• Problem: Ensure that the data being read/written remains
consistent
E.g. incrementing a counter
• Solution: ensure only one process accesses shared memory at a
time
• Use locks, semaphores, or monitors to protect critical sections
• Other Problems:
• Does not work across multiple machines
• Hard to debug
• Not always easy to reason about
• Hard to get right
• We can solve many of these problems by using message
passing.
Message Passing
Message Passing
• Features:
• Post-office or telephone model
• Processes can run on same or different machines
• Processes cannot read each others’ memory
• To communicate processes ask the system to send a
message on their behalf
• Real life example: the Internet
The Post-Office Analogy
• Suppose I am sending a postcard (message) to
someone
• Create postcard (message)
• Put destination and return (source) address on it
• Send it by dropping it into a post office box
• Post office delivers the post card to receiver’s mailbox
• The receiver then
• Retrieves postcard (and other letters) from mailbox
• Reads the postcard
• Processes (on different machines) can communicate
with each other in a similar fashion
Message Passing Operation
• The system (OS) provides a “post-office” facility
• A process can “send” or “receive” a message via the facility
• Operations
• send(dst, msg): send message to process specified by dst
• recv(src, msg): receive message from process specified by
src
• recvany(msg): receive message from any process
• Questions:
• How do we identify processes?
• How do processes learn about each other?
• Should the sender block until message is received?
• Should the receiver block until message is sent?
The Message Passing
(Post-Office) Facility
RAM
Kernel
Interrupt Table

Interrupt
Handler
Queues
P1
Interrupt
Handler P2
P42
P99

Message Passing Facility

Process Table

Proc 42
The Message Passing
(Post-Office) Facility
• Queue Pi stores messages (or senders) to the
process Pi
• The head of queue Pi is the next message to be
received by Pi Queues
P1
• To send a message processes must know the ID P2
or name of the process they are sending to P42
• The process asks the kernel to enqueue the P99
message on the corresponding queue
• To receive a message, it is not (always) Message Passing Facility
necessary for the process to explicitly specify
the sender
• The process asks the kernel to remove a message
from their queue and return it
• Analogy: A queue is the same as a mailbox
Process Naming
Process Naming
• How processes are named and how process names are
discovered is a whole topic beyond scope of this course
Example: On the Internet
• Processes are named by IP/port #
• Use DNS to look up IP addresses and port #s of specific
processes: e.g., 25 for e-mail (SMTP)
• Other Examples:
• On a single system each process has unique process ID (pid)
assigned by the OS
• Each thread has a unique thread ID (tid), assigned by the OS
or run-time system such as Java
• Another idea is to use a registry
Name Registry
• Analogy: A phone book
• Processes register their names on a central server
• Other processes can query server to find names
E.g., this is what DNS is Hello!
PID: 99
Registry Server ? Name:
ice
37 : Carol Al Dave
PID: 42
(42,Alice) 13 : Bob
Name: (42)
Alice 42 : Alice
Synchronous
Message Passsing
Should Processes Block?
• Questions:
• When a process sends a message, should it block until the
message is received?
• When a process receives a message, should it block until the
message arrives?
• Answers depend on the system:
• Typically, receivers will block until the message arrives
• Why?
• There are exceptions
• Whether senders should block depends on what type of
behaviour is desirable:
• Synchronous sends
• Asynchronous sends
Synchronous Send PID: 42
Name:

(Sender waits) Alice

“Hello”

• send(dst, msg): system call recv(99, msg )

• If receiver is not waiting to receive (blocked):
• Insert message (or process into queue)
• Sender is blocked Queues
• Else receiver is blocked: P1
• Copy message to receiver P2
• Receiver is unblocked (ready) P42
• Sender remains running or ready
P99
(can return from system call)
• recv(src, msg): system call
• If sender is not waiting to send (blocked):
• Receiver is blocked send(42,”Hello”)
• Else sender is blocked:
• Remove and copy message from queue PID: 99
• Sender is unblocked (ready) Name:
• Receiver remains running or ready Dave
(can return from system call)
Synchronous Send PID: 42
Name:

(Sender waits) Alice

“Hello”

• send(dst, msg): system call recv(99, msg )

• If receiver is not waiting to receive (blocked):
• Insert message (or process into queue)
• Sender is blocked Queues
• Else receiver is blocked: P1
• Copy message to receiver P2
• Receiver is unblocked (ready) P42
• Sender remains running or ready
P99
(can return from system call)
• recv(src, msg): system call
• If sender is not waiting to send (blocked):
• Receiver is blocked send(42,”Hello”)
• Else sender is blocked:
• Remove and copy message from queue PID: 99
• Sender is unblocked (ready) Name:
• Receiver remains running or ready Dave
(can return from system call)
Discussion of Synchronous
Send
• At end of operation both sender and receiver have
synchronized
i.e., Both know where they are
• Analogy: Telephone
• Does not require buffering. Why?
• Note recvany(msg) simply takes first
message/sender in queue
Asynchronous
Message Passsing
Asynchronous Send PID: 42
Name:

(No waiting) Alice

“Hello”

• send(dst, msg): system call recv(99, msg )

• If receiver is not waiting to receive (blocked):
• Copy and Insert message (or process into queue)
• Else receiver is blocked: Queues
• Copy message to receiver
P1
• Receiver is unblocked (ready) P2
• Sender remains running or ready P42
P99
(can return from system call)
• recv(src, msg): system call
• If message is not in queue:
• Receiver is blocked send(42,”Hello”)
• Else:
• Remove and copy message from queue PID: 99
• Receiver remains running or ready Name:
(can return from system call) Dave
Asynchronous Send PID: 42
Name:

(No waiting) Alice

“Hello”

• send(dst, msg): system call recv(99, msg )

• If receiver is not waiting to receive (blocked):
• Copy and Insert message (or process into queue)
• Else receiver is blocked: Queues
• Copy message to receiver
P1
• Receiver is unblocked (ready) P2
• Sender remains running or ready P42
P99
(can return from system call)
• recv(src, msg): system call “Hello”
• If message is not in queue:
• Receiver is blocked send(42,”Hello”)
• Else:
• Remove and copy message from queue PID: 99
• Receiver remains running or ready Name:
(can return from system call) Dave
Discussion of
Asynchronous Send
• Sender does not know when receiver gets the
message
• Analogy: Sending a letter or postcard
• Does require buffering. Why?
• Notes on recvany(msg)
• Simply takes first message/sender in queue
Producer Consumer
Solution with Message
Passing
void Producer() {
while (1) {
p = produce();
Send(consumer, p);
}
}

void Consumer() {
while (1) {
Recv(producer, p)
consume(p);
}
}