Phones OFF Please
This presentation is the property of its rightful owner.
Sponsored Links
1 / 27

Phones OFF Please PowerPoint PPT Presentation


  • 38 Views
  • Uploaded on
  • Presentation posted in: General

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).

Download Presentation

Phones OFF Please

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


Phones off please

Phones OFF Please

Inter-Process Communication (IPC)

Parminder Singh Kang

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

Email: [email protected]


Phones off please

  • 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.


Phones off please

  • 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


Phones off please

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


Phones off please

  • 2 Peer to Peer model and client/server model

    • Peer to Peer

  • Process AProcess 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, …


Phones off please

  • 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.


Phones off please

  • 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)


Phones off please

  • 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 :-


Phones off please

  • 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


  • Phones off please

    • 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.


    Phones off please

    • 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.


    Phones off please

    • 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


    Phones off please

    • 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.


    Phones off please

    • 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.


    Phones off please

    • 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.


    Phones off please

    • 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;


    Phones off please

    • 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


  • Phones off please

    • 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";


    Phones off please

    • 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])| |

    • ----------- ------------


    Phones off please

    • 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.


    Phones off please

    • 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.


    Phones off please

    • 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.


    Phones off please

    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.


    Phones off please

    • 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


    Phones off please

    • 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.


    Phones off please

    • 6.3 Synchronization and buffering

      • Synchronization

        • blocking send

        • non blocking send

        • blocking receive

        • non blocking receive

      • Buffering

        • zero capacity

        • finite capacity

        • infinite capacity


  • Login