Monitors

1
Monitors

• Motivation take complexity of designing mutual
  exclusion using semaphores out of application
  writers hands let compiler deal with mutual
  exclusion
• Monitors are programming language constructs, so
  limited use and implementation
• Rules
• Only one process can be active in monitor at any
  time
• Processes cannot access internal data of monitor
• Put all critical sections inside monitor
  procedures

2
Monitors

• Condition variables wait and signal
• Similar to sleep/wake up
• Processes wait on some variable
• Process is blocked
• Although process is inside monitor while blocked,
  another process can enter monitor because blocked
  process is not active
• Processes signal to waiting processes
• Signaling process must exit out of monitor
  immediately after issuing signal
• Signaled process wakes up inside monitor
• If more than 1 process waiting, one is picked by
  scheduler (same as with semaphores)

3
Monitors Producer-Consumer

• insert ( )
• if countN then wait (spaces)
• insert_item
• increment count
• if count1 then signal (items)
• remove ( )
• if count0 then wait (items)
• remove_item
• decrement count
• if countN-1 then signal (spaces)

4
Mutexes

• Binary semaphore with 2 states locked/unlocked
• Used to ensure mutual exclusion of critical
  sections
• Efficient, so good for user-level threads package
• Note that threads must explicitly yield if it
  cannot get the lock, since there are not clock
  interrupts for threads.

5
Message Passing

• Assumption made with semaphores, mutexes,
  monitors that memory is shared
• Is this an accurate assumption for threads?
• For processes?
• Semaphores and monitors provide synchronization
  but NOT exchange of data
• Solution is to use message passing.

6
Message Passing

• Typical operations
• send ( destination, message_ptr )
• receive ( address, message_ptr )
• Appropriate for distributed computing since
  shared memory is not required
• More expensive than semaphores, monitors, so
  often used for communication between processes on
  remote machines multicomputer programming

7
Message Passing Issues

• How to name destinations and bind them
• Model for data typing endpoints may have
  differing definitions of data types
• Should send/receive be blocking or non-blocking
• Network issues

8
Message Passing Naming Binding

• Binding when a name is mapped to an object
• Semi-dynamic addresses
• Dynamically allocated names
• NOT a process id
• Example Port numbers dynamically bound to static
  names
• Name server associates (static) string name
  with (semi-dynamic) port number
• DNS example

9
Message Passing Data Typing

• Marshalling linearizing complex data structures
  into sequence of bytes (or base types)
• Unmarshalling reconstruction of complex data
  structures from sequence of bytes
• Marshalling used to construct message for passing
• Unmarshalling used upon receipt of message to
  parse message content

10
Message Passing Data Typing

• Cannot predict or limit data type sent by process
• Should messaging system be aware of data types or
  just regard message as sequence of bytes?
• Unix sockets bytes
• Others limited set of base types (e.g., Mach
  messages)
• Advantages of having data types in protocol
• Can include objects that the OS must manipulate
• Have lower level layer than transparently
  byte-swap integers (Big vs. Little Endian) or
  other simple conversions
• Unmarshaling of data is easier since programmer
  does not need to do explicit conversion

11
Message Passing Blocking or Non-blocking

• Receive
• Blocking wait until message arrives
• Non-blocking check if message is present how?
• Wait interval should be timed
• What is returned to sender?
• Blocking return acknowledgement to sender
• Transmitted (unreliable)
• Delivered (reliable)
• Non-blocking message has been queued for
  transmission
• Message must be copied to OS-private buffer so
  that no process can change contents after sending

12
Message Passing Blocking or Non-blocking

• Rendezvous
• No mailbox
• Uses blocking
• When both send and receive operations are
  successful, message is copied directly from
  sender to receiver

13
Message Passing Network Issues

• Byte order
• Mandate a network byte order use hton and ntoh
  functions
• Receiver makes it right
• Reliable or unreliable delivery?
• Acknowledgement receiver sends ack to sender.
  If sender does not receive ack, retransmit
• Retransmissions
• How to distinguish original from resend?
• How to maintain original message segmentation?
• Authentication/security issues

14
Remote Procedure Call (RPC)

• Also used for multicomputer programming
• Avoids I/O of message passing incurred by
  send/receive calls
• Instead, allow processes to make procedure calls
  on other machines hence remote
• Need to make RPC look as much as possible like a
  local call

15
RPC Implementation

• Interface described in interface description
  language
• Stub compiler compiles interface description into
  client and server stubs
• Stubs linked into client and server programs
• Client stub marshalls data into messages server
  unmarshalls data

16
RPC Example

• Interface description
• int x, y, z
• foo (IN x, OUT y, INOUT z)
• Client stub
• foo (x, y, z)
• // marshall arguments from x and z
• // send ( ) message
• // receive ( ) response
• // unmarshall return values into y

17
RPC Example

• Server stub
• main ( )
• while (TRUE) do
• msg receive ( )
• demux (msg, response)
• send (response)
• foo (x, y, z) implemented as server-side
  application

demux (msg) switch (type_of_msg)
case foo // unmarshall arguments into
x and z // call foo //
marshall return values from y and z
break
18
RPC Example

• To client-side application, RPC is transparent
  cannot distinguish between RPC and other local
  procedures
• To server-side application, only message receive
  code needs to be added
• Both sides must add code to bind via name server
• How transparent?
• Binding code andaddress must be compiled into
  stubs
• Client will need to know how to interpret results
  received

19
RPC Issues

• Pointers as parameters client and server may
  not be running in the same address space
• Weakly typed languages such as C
• Use of global variables by server application
  that is unknown to client
• What to do when server or client crashes?

20
Traditional Inter-Process Comm. Problems

• Set of representative problems to be used for
  benchmarking when many synchronization algorithms
  and primitives were developed
• Critical section
• Producer-consumer
• Dining philosophers