More on Synchronization Interprocess Communication IPC

1
More on SynchronizationInterprocess
Communication (IPC)

• CS-3013 CS-502Summer 2006

2
Interprocess Communication

• Wide Variety of interprocess communication (IPC)
  mechanisms e.g.,
• Pipes streams
• Sockets Messages
• Remote Procedure Call
• Shared memory
• OS dependent
• Depends on whether the communicating processes
  share all or part of an address space

3
Interprocess Communication

• Common IPC mechanisms
• shared memory read/write to shared region
• E.g., shmget(), shmctl() in Unix
• Memory mapped files in WinNT/2000
• Need critical section management
• semaphores post_s() notifies waiting process
• Shared memory or not
• software interrupts - process notified
  asynchronously
• signal ()
• pipes - unidirectional stream communication
• message passing - processes send and receive
  messages
• Across address spaces

4
IPC Software Interrupts

• Similar to hardware interrupt.
• Processes interrupt each other
• Non-process activities interrupt processes
• Asynchronous! Stops execution then restarts
• Keyboard driven e.g. cntl-C
• An alarm scheduled by the process expires
• Unix SIGALRM from alarm() or settimer()
• resource limit exceeded (disk quota, CPU time...)
• programming errors invalid data, divide by zero

5
Software Interrupts (continued)

• SendInterrupt(pid, num)
• Send signal type num to process pid,
• kill() in Unix
• (NT doesnt allow signals to processes)
• HandleInterrupt(num, handler)
• type num, use function handler
• signal() in Unix
• Use exception handler in WinNT/2000
• Typical handlers
• ignore
• terminate (maybe w/core dump)
• user-defined

6
Software Interrupts (continued)

• Will need to use software interrupts for
  Programming Project 3 (Web Server)
• For cleanly exiting the server

7
IPC Pipes

• A pipe is a unidirectional stream connection
  between 2 processes
• Unix/Linux
• 2 file descriptors
• Byte stream
• Win/NT
• 1 handle
• Byte stream and structured (messages)

8
IPC Pipes
include ltiostream.hgt include ltunistd.h include
ltstdlib.hgt define BUFFSIZE 1024 char data
whatever int pipefd2 / file descriptors for
pipe ends / / NO ERROR CHECKING, ILLUSTRATION
ONLY!!!!! / main() char sbBufBUFFSIZE
pipe(pipefd) if (fork() gt 0 ) / parent,
read from pipe / close(pipefd1) / close
write end / read(pipefd0, sbBuf, BUFFSIZE)
/ do something with the data / else /
child, write data to pipe / close(pipefd0)
/ close read end / write(pipefd1, data,
sizeof(DATA)) close(pipefd1) exit(0)

9
IPC Message Passing

• Communicate information from one process to
  another via primitives
• send(dest, message)
• receive(source, message)
• Receiver can specify ANY
• Receiver can choose to block or not
• Applicable to multiprocessor and distributed
  systems

10
IPC Message Passing
void Producer() while (TRUE) / produce item
/ build_message(m, item) send(consumer, m)
/ send message / receive(consumer, m) / wait
for ack / void Consumer while(TRUE)
receive(producer, m) / receive message
/ extract_item(m, item) send(producer,
m) / send ack / / consume item /
11
IPC Message Passing

• send ( ) operation
• Synchronous
• Returns after data is sent
• Blocks if buffer is full
• Asynchronous
• Returns as soon as I/O started
• Done?
• Explicit check
• Signal
• Blocks if buffer is full
• receive () operation
• Sync.
• Returns if there is a message
• Blocks if not
• Async.
• Returns if there is a message
• Returns indication if no message

12
IPC Message Passing

• Indirect Communication mailboxes
• Messages are sent to a named area mailbox
• Processes read messages from the mailbox
• Mailbox must be created and managed
• Sender blocks if mailbox is full
• Enables many-to-many communication

13
Message Passing issues

• Scrambled messages (checksum)
• Lost messages (acknowledgements)
• Lost acknowledgements (sequence no.)
• Process unreachable (down, terminates)
• Naming
• Authentication
• Performance (copying, message building)

14
Beyond Semaphores

• Semaphores can help solve many traditional
  synchronization problems, BUT
• Have no direct relationship to the data being
  controlled
• Difficult to use correctly easily misused
• Global variables
• Proper usage requires superhuman attention to
  detail
• Another approach use programming language
  support

15
Monitors

• Programming language construct that supports
  controlled access to shared data
• Compiler adds synchronization automatically
• Enforced at runtime
• Encapsulates
• Shared data structures
• Procedures/functions that operate on the data
• Synchronization between processes calling those
  procedures
• Only one process active inside a monitor at any
  instant
• All procedures are part of critical section
• Hoare, C.A.R., Monitors An Operating System
  Structuring Concept, Communications of ACM, vol.
  17, pp. 549-557, Oct. 1974 (.pdf)

16
Monitors

• High-level synchronization allowing safe sharing
  of an abstract data type among concurrent
  processes.
• monitor monitor-name
• shared variable declarations
• procedure body P1 ()
• . . .
• procedure body P2 ()
• . . .
• procedure body Pn ()
• . . .
• initialization code

17
Monitors
shared data
at most one process in monitor at a time
operations (procedures)
18
Monitors

• Mutual exclusion
• only one process can be executing inside at any
  time
• if a second process tries to enter a monitor
  procedure, it blocks until the first has left the
  monitor
• Once inside a monitor, process may discover it is
  not able to continue
• condition variables provided within monitor
• processes can wait or signal others to continue
• condition variable can only be accessed from
  inside monitor
• waiting process relinquishes monitor temporarily

19
Monitors

• To allow a process to wait within the monitor, a
  condition variable must be declared, as
• condition x, y
• Condition variable can only be used with the
  operations wait and signal.
• The operation
• wait(x)means that the process invoking this
  operation is suspended until another process
  invokes
• signal(x)
• The signal operation resumes exactly one
  suspended process. If no process is suspended,
  then the signal operation has no effect.

20
wait and signal (continued)

• When process invokes wait, it reliquishes the
  monitor lock to allow other processes in.
• When process invokes signal, the resumed process
  must reacquire monitor lock before it can proceed
  (inside the monitor)

21
Monitors Condition Variables
22
Monitors
monitor ProducerConsumer condition full, empty
integer count 0 / function prototypes
/ void insert(item i) item remove() void
producer() void consumer()
void producer() item i while (TRUE)
/ produce item i / ProducerConsumer.insert
(i) void consumer() item i while
(TRUE) i ProducerConsumer.remove() /
consume item i /
23
Monitors

• void insert (item i)
• if (count N) wait(full)
• / add item i /
• count count 1
• if (count 1) then signal(empty)
• item remove ()
• if (count 0) wait(empty)
• / remove item into i /
• count count - 1
• if (count N-1) signal(full)
• return i

24
Monitors variations

• Hoare monitors signal(c) means
• run waiter immediately (and acquires monitor
  lock)
• signaler blocks immediately (and releases lock)
• condition guaranteed to hold when waiter runs
• Mesa/Pilot monitors signal(c) means
• waiter is made ready, but signaler continues
• waiter competes for monitor lock when signaler
  leaves monitor (or waits)
• condition is not necessarily true when waiter
  runs again
• being woken up is only a hint that something has
  changed
• must recheck conditional case

25
Monitors (Mesa)

• void insert (item i)
• while (count N) wait(full)
• / add item i /
• count count 1
• if (count 1) then signal(empty)
• item remove ()
• while (count 0) wait(empty)
• / remove item into i /
• count count - 1
• if (count N-1) signal(full)
• return i

26
Synchronization

• Semaphores
• Easy to add to any language
• Much harder to use correctly
• Monitors
• Easier to use and to get it right
• Must have language support
• See
• Lampson, B.W., and Redell, D. D., Experience
  with Processes and Monitors in Mesa,
  Communications of ACM, vol. 23, pp. 105-117, Feb.
  1980. (.pdf)
• Redell, D. D. et al. Pilot An Operating System
  for a Personal Computer, Communications of ACM,
  vol. 23, pp. 81-91, Feb. 1980. (.pdf)

27
Break

• (next topic)