slide1
Download
Skip this Video
Download Presentation
Phones OFF Please

Loading in 2 Seconds...

play fullscreen
1 / 27

Phones OFF Please - PowerPoint PPT Presentation


  • 53 Views
  • Uploaded on

Phones OFF Please. Inter-Process Communication (IPC) Parminder Singh Kang Home: www.cse.dmu.ac.uk/~pkang Email: [email protected] IPC Most modern operating systems are multi-tasking (e.g. Unix, O/S2, Linux, Windows Nt, Windows 95).

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Phones OFF Please' - clare


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Phones OFF Please

Inter-Process Communication (IPC)

Parminder Singh Kang

Home: www.cse.dmu.ac.uk/~pkang

Email: [email protected]

slide2

IPC

    • Most modern operating systems are multi-tasking (e.g. Unix, O/S2, Linux,
    • Windows Nt, Windows 95).
    • Distributed environment, client/server (processes could be on different CPU\'s.)
    • IPC; a mechanism to allow processes to communicate and to synchronize
    • their actions without sharing same address space. distributed computing
    • environment; where processes may reside on different machines over network.
    • Often processes want to communicate. We can split them into two types:-
  • Uniprocessor IPC multiprocessor IPC
  • / \
  • Distributed systems Multi-CPU systems
  • (Networked) (Shared bus)
    • The O/S provides most mechanisms, but some are language dependent
    • Usually processes form a client/server or consumer/producer relationship.
slide3

2 Producer/Consumer relationship

    • One process generates data, the other receives it, i.e. producer/consumer
    • Synchronization, e.g. we have a loop where
      • Producer generates some data
      • Consumer reads the data
    • Condition;
      • Consumer needs to know when data has been produced.
      • Producer needs to know when it can produce more data.
    • Communication is based on handshaking (as in hardware and I/O devices)
    • Producer/Consumer process is
    • Producer  Buffer  Consumer
    • Need a variable – freeslots –indicates if anything is in buffer
slide4

Producer algorithm:

loop

if freeslots > 0 then

add an item

decrease freeslots by 1

endloop

Consumer algorithm:

loop

if freeslots < BUFSIZE then

remove an item

increase freeslots by 1

endloop

slide5

2 Peer to Peer model and client/server model

    • Peer to Peer
  • Process A Process B
  • send message  rec message
  • rec message  send message
    • Client/Server
  • Client Server
  • loop
  • send message  wait for message
  • rec message  send message
  • end loop
  • Note server runs continuously in a loop. Client runs then finishes.
    • UNIX servers called daemons, e.g.
      • Clients telnet, ftp …
      • Sever daemons are telnetd, ftpd, …
slide6

3 Overview of I.P.C. Mechanisms

    • Shared memory:
    • only one process can access memory at a time (mutual exclusion). We can use;
    • Signals - unreliable. Signals aren\'t queued, so some can get lost.
    • Semaphores - low level. Make a mistake and everything goes to sleep.
    • Event-counters - simpler than semaphores. Not very common but not guaranteed.
    • Message passing
    • Pipes or unbound sockets - only used by related processes. Easy to use.
    • Synchronisation controlled by O/S
    • Sockets - Similar to pipes/file access. Can be used across network. Different
    • varieties - guaranteed delivery (virtual circuits), unreliable (datagram)
    • Rendezvous - similar to pipes/sockets but no buffering. Used in Occam and Ada.
slide7

Shared files - similar to shared memory in virtual memory systems, since the file

  • can be memory mapped. Can include record locking to enable synchronising.
  • Named pipes - similar to pipes, but used by unrelated processes.
  • Message passing. Similar to pipes, sockets, etc, but message boundaries preserved.
  • Remote Procedure Call (RPC)
slide8

4. Shared Memory

    • The most efficient IPC mechanism is probably shared memory.
    • .------------. .------------. .------------.
  • | | | Shared | | |
  • | Process A |-------->| Memory |----------> | Process B |
  • | | | | | |
  • ------------ ------------ ------------
    • If we allow uncontrolled access we can get race conditions –
    • Results depend on which process accesses memory.
    • For example, consider process A is a producer, and process B is a consumer.
    • Process A is putting data into a buffer (the shared memory), process B
    • is removing it.
    • To control access we have a shared variable called ItIsFree, which is true
    • when no process is accessing the buffer. The two processes might look like :-
slide9

Process A Process B

  • LOOP LOOP
  • IF ItIsFree then IF ItIsFree then
  • ItIsFree := FALSE ItIsFree := FALSE
  • put data in buffer take data from buffer
  • ItIsFree := TRUE ItIsFree := TRUE
  • END END
  • END END
    • Problems can occur if testing and setting ItIsFree is not a single operation.
  • Process A Process B
  • |
  • does test - ItIsFree is TRUE does test - ItIsFree is TRUE
  • set ItIsFree FALSE set ItIsFree FALSE
  • now both accessing the buffer at the same time
slide10

Note: The section of code which accesses the shared memory is called the critical section. To ensure race conditions cannot occur we need mutual exclusion - only one process is in its critical section at a time.

    • Avoidance:  
      • No two processes simultaneously in their critical sections.
      • No assumption should be made about speed or number of CPU\'s.
      • Processes outside their critical region should not be able to block other processes.
      • No process should have to wait forever to enter its critical section.
slide11

4.1 Access control - TAS instruction

    • To control access we want an indivisible instruction which can test and set a variable in one operation.
  • label: TAS variable ; test the access variable
  • BNE label ; wait for zero
  • :
  • critical section of code using shared region
  • :
  • CLR.B variable ; set to 0 to allow access
  • This is of little use since it uses busy-waiting (the TAS loop) and is a waste of CPU time.
slide12

4.2 Access control - Sleep and Wakeup

    • Process should sleep until the region is clear, then be woken up.
    • system calls:
      • sleep send process to sleep
      • wakeup wake process up. (i.e. make it ready to run)
    • The mechanism;
      • producer has produced some output, wakes the consumer and goes
      • to sleep itself.
      • When the consumer has consumed the input it wakes the producer
      • and sends itself to sleep. So the two processes alternate and wake each other.
    • What if signal Lost?
      • the producer reads the flag and finds it zero
      • but before it can go to sleep the consumer is scheduled
slide13

the consumer sends a wakeup, which gets lost, since nothing is asleep yet

  • the consumer then goes to sleep, waiting for the producer to wake it
  • the producer resumes and completes its sleep operation.
  • Both then sleep forever.
  • The solution is to store the wakeups - we then have the semaphore.
slide14

4.3 Access control - Semaphores

    • A semaphore is a cardinal variable, with an associated list of sleeping processes.
    • plus two atomic operations, which can be performed on it.
    • The two operations are DOWN(s) and UP(s) both will be system calls
    • (s is the semaphore. Definition:-
    • DOWN(s): If s = 0 then
    • send process to sleep
    • Else
    • decrement s
    • End
  • UP(s): If any processes asleep on s then
  • wake one (i.e. make it ready to run)
  • Else
  • increment s
  • End
    • If s only takes the values 0 and 1 it is a binary semaphore,
    • otherwise it is a general semaphore.
slide15

Semaphores are only used to enable processes to synchronise themselves.

    • i.e. to ensure only one process enters a critical region at a time.
  • In typical use each process will have the following:
  • DOWN(s)
  • :
  • critical section
  • :
  • UP(s)
  • Initially s is set to 1.
  • If process A runs first and does a DOWN, Set S to 0.
  • Once A has completed the DOWN it can be interrupted, even if it is still in
  • its critical section. Suppose this happens and process B is set running.
  • If it does the DOWN it will be sent to sleep. Process A will eventually be
  • set running again and will do an UP on exiting its critical region.
  • This will wake up B. Note we can have more than two processes.
slide16

4.4 Access control - event counters

    • Like the semaphore an event counter is a cardinal variable with
    • an associated list of sleeping processes.
    • Apart from initialising the are 3 operations which can be performed;
    • READ(e) read the value of \'e‘
    • ADVANCE(e) increment \'e‘
    • AWAIT(e,v) wait until \'e\' has a value of \'v\' or more.
    • Like semaphores they are atomic system calls.
    • For example in the producer/consumer situation, we could have:
  • ine = 0; oute = 1;
  • pseq = 0; cseq = 0;
slide17

then the producer would be

  • LOOP
  • :
  • produce an item
  • inc(pseq)
  • AWAIT(oute, pseq)
  • put item in the buffer
  • ADVANCE(ine)
  • :
  • END
  • and the consumer would be
  • LOOP
  • :
  • Inc(cseq)
  • AWAIT(ine, cseq)
  • get item from buffer
  • ADVANCE(oute)
  • :
  • END
slide19

5 UNIX IPC

  • 5.1 Pipes
    • Unix originally just had the pipe as the IPC mechanism.
    • Pipe is a convenient high level mechanism; created with system call,
    • int pipe(int filedes[2]);
    • pipe creates a pair of file descriptors, pointing to a pipe i-node
    • places them in the array pointed to by filedes.
      • filedes[0] is for reading
      • filedes[1] is for writing.
      • On success, zero is returned, on error, -1 is
  • #include <unistd.h>
  • int fd[2], rval;
  • if ((rval = pipe(fd)) < 0) cout << " error creating pupe";
slide20

Performing Read and Write:

    • Read; block an empty pipe until some data is put into the pipe.
    • Process fills a pipe it blocks until some bytes are removed from the pipe.
    • The read command will return with zero bytes when end of file is met,
    • When the pipe has no writing processes left.
  • A single pipe can be used to send information one way or the other, i.e.:
  • ----------- ------------
  • | | write(p[1]) read(p[0]) | |
  • | |======>===========--==========>======= | |
  • | parent| || | child |
  • | |======<===========__==========<======= | |
  • | | read(p[0]) write(p[1])| |
  • ----------- ------------
slide21

Either the child or parent writes; not both at the same time.

  • To have simultaneous two way communication you can have two pipes,
  • say p and q. It usual to close the ends of the pipe down you don\'t want,
  • e.g. after the fork command the parent can close q[0] and p[1],
  • Child can close q[1] and p[0]. Thus the parent writes into q and reads
  • from p, and the child writes to p and reads from q.
slide22

6. Message Passing System

    • Communication among user processes is accomplished by passing messages.
    • At lease two operations are required;
      • send (Message)
      • receive (Message)
    • Messages can be of variable or fixed size.
      • Fixed size; system level implementation is easy but programming task is difficult.
      • Variable size; Complex system level implementation but programming is much simpler.
slide23

Several Methods for logical implementation

    • Direct or indirect communication.
    • Symmetric or Asymmetric communication.
    • Automatic or Explicit buffering.
    • Send by Copy or Send by Reference.
    • Fixed size or Variable size messages.
slide24

6.1 Direct communication:

Direct Communication

Symmetric naming

  • sender and receiver have name of each process.
  • send(p,message) -> sends message to p
  • receive(q,message)-> receive message from q
  • Asymmetric naming
  • only sender names recipient; receiver uses id instead of name.
  • send (p,message)  send message to p
  • receive(id,message)  receive message from any process.
slide25

conditions;

    • automatic link should be established between two processes.
    • a link should be associated only with two processes.
    • exactly one link should exists between pair of processes
slide26

6.2 Indirect communication:

    • Messages are sent or received from mailboxes or port.
    • Implementation;
      • create new mailbox.
      • send and receive message through mail box.
      • delete mailbox.
    • send(A,message)  send message to mailbox A
    • receive(a,message)  receive message from mailbox A
    • Communication link properties;
      • Link is only established if both processes r member of same mailbox.
      • Link can be associated with more than one processes.
      • A number of different links can be exists between each pair of communicating process.
slide27

6.3 Synchronization and buffering

    • Synchronization
      • blocking send
      • non blocking send
      • blocking receive
      • non blocking receive
    • Buffering
      • zero capacity
      • finite capacity
      • infinite capacity
ad