Concurrency III

1
Concurrency III

• Monitors
• Message Passing
• Readers and Writers

2
Outline

• Categories of Solutions to CS Problem
• Monitors A High-Level Language Solution to the
  CS Problem
• Interprocess Communication - Message Passing
• Another Classic Synchronization Problem The
  Readers and Writers Problem

3
Solutions to the Critical Section Problem

• Software requires no assistance from OS,
  compiler, hardware. Petersons algorithm
• Hardware Based on indivisible instructions such
  as Test_and_Set
• OS Synchronization services provided by the OS.
  Example semaphore
• Language Solutions provided by a high-level
  language. Example the monitor

4
Monitors A High-Level Language Solution to CS

• Historically, one of the most important language
  synchronization tools.
• High-level language constructs that encapsulate
  code and data.
• Have been implemented in several languages,
  including Concurrent Pascal, Modula-3, and Java.

5
Monitor Definition

• A monitor is a software module containing
• an initialization sequence, which runs once
• one or more procedures
• local data
• Only one process at a time can be in the
  monitor i.e., executing a monitor procedure
• Monitors provide ME by encapsulating code and
  data.

6
Similarity of Monitors Objects

• Processes enter the monitor by calling one of
  the procedures.
• Local data is accessible only to the procedures
  that are in the monitor.

7
Condition Variables

• Monitors provide mutual exclusion they must also
  provide other synchronization.
• It must be possible to block a process (e.g.,
  block producer if no empty slots) and release the
  monitor so another process can enter it.
• Solution condition variables

8
Condition Variables

• Contained in the monitor
• Operated on by two functions
• cwait(c) suspends process executing it makes
  monitor available to other processes
• csignal(c) resume a process that blocked on this
  condition

9
(No Transcript)
10
(No Transcript)
11
(No Transcript)
12
Monitors versus Semaphores

• Semaphores are sufficient to solve any mutual
  exclusion or synchronization problem, but there
  are drawbacks.
• For example, its hard to ensure that all
  cooperating processes use semaphores correctly
  (See next slide)
• Monitors (and other high-level language
  solutions) are potentially easier to use.

13
Incorrect Use of Semaphores(semaphores s and k
are initialized to 1)

• Process 0
• 01 wait(s)
• 02 wait(k)
• CS
• 03 signal(k)
• 04 signal(s)
• Some execution orders

• Process 1
• 11 wait(k)
• 12 wait(s)
• CS
• 13 signal(s)
• 14 signal(k)
• will lead to deadlock.

14
Semaphores and Monitors

• Monitors are also subject to error for example,
  the programmer could forget the cwait(notfull)
  instruction.
• Advantage all synchronization operations are
  centralized in the monitor

15
Javas Synchronization

• Java methods can be declared using the
  synchronized key wordpublic synchronized void
  append(int value)
• Only one thread at a time can execute the method
• Java also provides wait( ) and notify( ) methods
  that resemble the wait and signal statements in a
  traditional monitor

16
Interprocess Communication (IPC) Message
Passing

• Semaphores and monitors provide a way for
  processes to communicate by passing simple
  signals.
• IPC based on these techniques require shared
  memory all processes need to be able to access
  the semaphore variable, the buffers, etc.

17
Message Passing

• Message passing is a more general method for IPC.
• Used in distributed systemsno shared memory
• Can also be used in a shared memory computer
• Message passing can be used for synchronization
  and mutual exclusion, as well as for more general
  forms of information exchange.

18
Message Passing Primitives

• Message passing is based on two primitives
• send(destination, message)
• receive(destination, message)
• The message is composed in the senders address
  space and transferred (by the kernel) to the
  receivers address space.
• The kernel may buffer the message in kernel space.

19
Design Issues for Messaging

• How sender and receiver will synchronize
• How sender and receiver will address each other
  (naming)
• How the message will be formatted.
• Queuing discipline for multiple messages (FIFO
  versus priority)

20
Synchronizationblocking or non-blocking

• For sends
• non-blocking send message, continue to run
• blocking send message, wait till its delivered
• For receives
• non-blocking if message isnt available,
  continue to run
• blocking if message isnt available, wait.
• In either case, if message is available, receive
  and continue to run.

21
Message Passing Synchronization

• Blocking sends may have variations
• block the sender just until the message has been
  sent (in network communication) or
• block until the message has been received.
• Receives (blocking or not) never require the
  receiver to wait if a message has already arrived.

22
Message Passing Synchronization

• Common combinations
• Blocking send, blocking receiveOtherwise known
  as a rendezvous. Processes are synchronized at
  the message-exchange.
• Non-blocking send, blocking receiveSender can
  continue to run, perhaps sending messages to
  several servers. Receiver (e.g. a server) may
  have nothing to do unless a message is present,
  so just waits.

23
Addressing

• Addressing specifies how the receiver or sender
  of a message will be named.
• Direct addressing
• send/receive explicitly name destination/source
  process. In network message passing, this means
  knowing IP number and process id.
• Flexibility is limited. You cant, for example,
  switch to a back-up server without changing
  client code.

24
Addressing

• Indirect addressing is more versatile
• Messages are sent to a message queue, often given
  the generic name mailbox.
• In network communication, the most common devices
  are ports and sockets.
• Ports are mailboxes that are bound to one
  receiver process, although many processes may
  send to the port.

25
Mailboxes and Ports

• A mailbox can be private, or shared among several
  senders and receivers
• A port is associated with one receiver, multiple
  senders
• used for client/server applications the receiver
  is the server
• UNIX added sockets on top of ports

26
Ports and Sockets

• The socket abstraction is used in the TCP/IP
  protocols of the Internet.
• Internet IPC transmits a message from a socket in
  the sender to a socket in the receiver.
• Each socket must be bound to a port (and an IP
  address).
• Writing to a socket is based on the abstraction
  of writing to a file.

27
Message Format

• Depends at least partly on whether the message
  passing system is used on a single computer, or
  in a distributed system.
• Messages generally consist of a header, which
  identifies the recipient and may contain
  information for routing, decoding, etc. and then
  the message itself.
• In a network the message is usually broken up
  into packets that are sent individually.

28
Mutual Exclusion

• Processes can enforce mutual exclusion with
  message passing.
• The set of processes will share a mailbox (mutex)
  to which all can send and receive.
• Initially the mailbox has a single message.
• Assume non-blocking send, blocking receive
  primitives are used.

29
Mutual Exclusion

• The first Pi to execute receive() gets the
  initial message and enters CS.
• Other processes will be blocked until Pi resends
  the message.
• This assumes a message is only delivered to one
  process, and that all other receivers block.

Process Pi var msg message repeat
receive(mutex, msg) CS send(mutex, msg)
RS forever
30
Client-Server

• Microkernel OSs are typically based on the
  client-server model. Servers communicate by
  sending messages through the kernel.
• Client-server protocols in a distributed system
  are also based on message passing.

31
Remote Procedure Calls (RPC)

• RPC provides a high level interface to message
  passing.
• The message send primitive resembles a procedure
  (function) call.
• The procedure name identifies the recipient
  parameters contain message content.
• RPC is usually synchronous blocking send,
  blocking receive.

32
Readers and Writers A Classic Synchronization
Problem

• Another classic problem in synchronization and
  concurrency (like producer/consumer).
• Characteristics
• concurrent processes access shared data area
  (files, block of memory, set of registers)
• some processes only read information, others
  write (modify and add) information

33
Readers and Writers

• Conditions that must be satisfied
• Any number of readers may simultaneously read the
  data area (reads are non-destructive)
• Only one writer at a time may access the data
  area.
• Readers may not access the data while writers are
  writing (to prevent the reader from retrieving
  inconsistent data)

34
Readers and Writers

• Differences between Readers/Writers (R/W) and
  Producer/Consumer (P/C)
• Data in P/C is ordered - placed into buffer and
  retrieved according to FIFO discipline.
• In R/W, same data may be read many times by many
  readers, or data may be written by writer and
  changed before any reader reads.
• Differences between R/W and simple M/E
• R/W requires M/E and synchronization

35
Readers and Writers

• Some solutions to R/W problem give readers
  priority as long as there are readers wanting to
  read, no writer can write.
• Problem writer starvation. If writers arent
  allowed to update, readers will get stale data.
• Other solutions give priority to writers
• Problem reader starvation. If readers arent
  allowed to read, the data is useless.

36
Solution to R/W

• The following solution uses a variable, shared by
  readers, and two semaphores
• readcount (shared variable) counts the number of
  readers who are currently active.
• x (semaphore) ensures mutual exclusion when
  readers modify the shared variable readcount.
• wsem (semaphore) ensures mutual exclusion for the
  shared data used by readers and writers.

37
procedure writer begin repeat wait
(wsem) WRITEUNIT signal (wsem)
forever end Fig. 5.22, page 243
integer readcount 0 /initialize semaphore x,
wsem 1 /initialize procedure reader begin
repeat wait (x) readcount
readcount 1 if readcount 1 then
wait (wsem) signal (x) READUNIT()
wait (x) readcount readcount -
1 if readcount 0 then signal (wsem)
signal (x) forever end
38
R/W Solution

• All writers wait on wsem to be sure the data can
  be read with mutual exclusion.
• Only the first reader waits on wsem. Subsequent
  readers (readcount gt1) proceed to read operation
  automatically.
• When the last reader finishes, it signals wsem.
  If there are waiting writers, one will be
  returned to the Ready state.

39
Summary

• The central themes of modern operating systems
  are multiprogramming, multi- processing, and
  distributed processing. Fundamental to these
  themes, and fundamental to the technology of
  operating system design, is concurrency. When
  mul-tiple processes are executing concurrently,
  either actually or virtually , issues of
  conflict resolution and cooperation arise.