Intro to IPC

Objectives

1. Understand the basics of IPC

Notes

• 3.4 - 3.6 and some.
• I Have a problem
  • Using information form Euler, $\pi = 4(\Sigma_1^{\infty} (-1)^i\frac{1}{2i+1} = 4(1 -\frac{1}{3} + \frac{1}{5} \cdots)$
  • How could we parallelize this?
  • Idea 1: Each process has an id
    • Process n sums from i = k × id, to i = k ×(id+1)-1
    • Then each just needs to send back the result to the lead process
  • Idea 2, the lead process divides the problem into smaller work units
    • It sends a work unit to each process on request
    • The process returns the work and asks for a new chunk.
  • In both cases we would need the ability to
    • Return an answer
    • And to indicate that we have finished.
• He lists two other reasons we might want IPC
  • Information sharing
  • Computational Speedup (I think this is the above task)
  • Modularity - micro kernel idea
• The book discusses two forms of interprocess communications
  • Shared memory (SYS V shared memory)
  • Message Passing (Pipes (fifos), sockets)
• Shared Memory
  • As we have discussed, one of the main tasks of an OS is memory management.
  • It makes sense that we can have processes share memory.
    • Generally one process will set up a shared memory segment.
      • shm_open: creates a new shared memory segment,
      • ftruncate: to set the size
      • mmap: to map the memory to a variable in the program.
      • use the memory
    • Other processes will connect to this segment.
      • shm_open
      • mmap
      • use the memory
      • shm_unlink free the memory
    • It means that the processes need to know how memory is to be used.
    • And they need a synchronization process, we don't have that yet and we would need the kernel to provide it.
    • I have implemented the Book's code (133 and 134) and even corrected their error.
    • How would we do this with the pi problem.
• Message passing
  • This generally invoves a system that involves
    • send(message)
    • recv(message)
  • These two can provide a level of synchronization
    • Ie the messages themselves are a synchronization mechanism.

      Boss:
          send a message to each process consisting of start and stop values
          set work to the number of processes
          while there is work out:
             wait on a return message
             receive that message,
                 add the result to pi
                 if there is data 
                    send a new message to the source with new start and stop values
                 else 
                    send a message to the source with exit
                    decrement work
      Worker:
          done = false
          repeat
              receive a message 
              if it is a work message
                  do the work
                  send a message back with the results
              else if it is a exit message
                  set done to be true
           until done 

  • This level of synchronization is not the best
    • Many could be blocked waiting on service.
    • Ie blocking receive: stop and wait for a message.
    • You might have a blocking send as well.
  • Message passing systems might have coded in the message
    • Addresses
    • Content identification
  • Or they might have different ports which things will connect to.
• They discuss buffers
  • Bound and unbound buffers
  • Look at bufferDemo.cpp
  • In this case, in, out and buffer need to be shared.
  • And care must be taken to assure that in and out are not updated at the same time.
    • Otherwise we will have non-deterministic behavior
  • The keen observer will see an array based queue.
    • Which is what this is.
    • In points to the next available space
    • Out points to the last used space
    • If they are equal, then the buffer is empty
    • If in is one less than out, then the buffer is full.
  • We would probably need semaphores and a critical section to do this.
  • But that is section three
• Take a look at pi.cpp