1 / 31

Chapter 6

Chapter 6. Interprocess Communications. Contents. Introduction Universal IPC Facilities System V IPC. Introduction. The purposes of IPC: Data transfer Sharing data Event notification Resource sharing Process control. 6.2. Universal IPC Facilities. Signals Kill Sigpause ^C

muhammed
Download Presentation

Chapter 6

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 6 Interprocess Communications

  2. Contents • Introduction • Universal IPC Facilities • System V IPC

  3. Introduction • The purposes of IPC: • Data transfer • Sharing data • Event notification • Resource sharing • Process control

  4. 6.2. Universal IPC Facilities • Signals • Kill • Sigpause • ^C • Expensive • Limited: only 31 signals. • Signals are not enough.

  5. P P P Data P P Fig 6-1 Data flow through a pipe. Pipes • A unidirectional, FIFO, unstructured data stream of fixed maximum size. • int pipe (int * filedes) • filedes[0] for read, filedes[1] for write

  6. Pipes • Applications: in shell – passing output of one program to another program – e.g. cat fil1 file2 | sort • Limitations:cannot be used for broadcastng; • Data in pipe is a byte stream – has no structure • No way to distinguish between several readers or writers • Implementation – by using file system mechanisms, sockets or STREAMS, • Alternative: FIFO – named pipe – may be accessed by unrelated processes, is persistent, has a name; - but must be explicitly deleted when not used, less secure than pipe,

  7. SVR4 Pipes • Bidirectional: • status = pipe(int fildes[2]); • write to fildes[1] & read from filde[0] • Or vice versa • status = fattach(int fildes, char *path) • fdetach()

  8. Process Tracing • ptrace(cmd, pid, addr, data) • pid is the process ID • addr refers to a location • cmd: r/w, intercept, set or delete watchpoints, resume the execution • Data: interpreted by cmd • Used by debuggers sdb or dbx

  9. Process Tracing • drawbacks and limitations - child must allow tracing explicitly by invoking ptrace; – parent can control the execution of its direct children only; - extremely inefficient (requires several context switches); - cannot control a process already running; - security problems when tracing a setuid programs (user can obtain superuser privileges) – to avoid this UNIX disables tracing such programs; • current debuggers use different approach.

  10. 6.3. System V IPC • Common Elements • Key: resource ID • Creator: IDs • Owner: IDs • Permissions: r/w/x for g/owner/others

  11. 6.3. System V IPC • Common Elements • General name: ipc resource • Similar system calls: shmget, semget, msgget • Similar control mechanisms • Each ipc resource must be explicitly deallocated and removed • Each type of ipc resource has its own fixed-size resource table

  12. Semaphores • Special variable called a semaphore is used for signaling • If a process is waiting for a signal, it is suspended until that signal is sent • Wait and signal operations cannot be interrupted • Queue is used to hold processes waiting on the semaphore

  13. P/V Operations • P(wait): • s=s-1; • if (s<0) block(); • V(signal): • s= s+1; • if (s>=0) wake();

  14. Producer/Consumer Problem • One or more producers are generating data and placing these in a buffer • A single consumer is taking items out of the buffer one at time • Only one producer or consumer may access the buffer at any one time • Two semaphores are used • one to represent the number of items in the buffer • one to signal that it is all right to use the buffer

  15. Producer Function #define SIZE 100 semaphore s=1 semaphore n=0 semaphore e= SIZE void producer(void) {while (TRUE){ produce_item(); wait(e); wait(s); enter_item(); signal(s); signal(n); } }

  16. Consumer Function void consumer(void) {while (TRUE){ wait(n); wait(s); remove_item(); signal(s); signal(e); } }

  17. Semaphore • semid = semget(key, count, flag) • status = semop(semid, sops, nsops) • struct sembuf{ • unsigned short sem_num; • short sem_op; /*>0; =0, <0*/ • short sem_flg; • } Add sem_op to the value, wake up Block until the value becomes zero Block until the value becomes greater than or equal to the absolute value of sem_op, then subtract sem_op from that value

  18. Semaphore implementation struct semid_ds{ struct ipc_perm sem_perm; struct sem* sem_base; ushort sem_nsems; time_t sem_otime; tiem_t sem_ctime; } struct sem{ ushort semval; pid_t sempid; ushort semncnt; ushort semzcnt; }

  19. An example of semaphore Semid_ds Semid sem_val sem_pid sem_ncnt sem_zcnt sem_val Sem_pid sem_ncnt sem_zcnt sem_perm sem_base sem_nsems sem_otime sem_ctime [ 0 ] [ 0 ] [ 0 ] [ 0 ] [ 1 ] [ 1 ] [ 1 ] [ 1 ]

  20. Deadlock of semaphores lock S2 Proc A S1 Proc B lock

  21. Problems with semaphores • Deadlock detection and avoidance left to the applications. • Sem allocation and initialization is not atomic – may lead to race conditions, • Sem must be explicitly removed -garbage collection problem

  22. Message Queue • msgqid = msgget(key, flag) • msgsnd(msgqid, msgp, count, flag) • struct msqid_ds { struct ipc_perm msg_perm; struct msg* msg_first; struct msg* msg_last; unshort msg_cbytes; unshort msg_qbytes; unshort msg_qnum; } • count =msgrcv(msgqid, msgp, maxcnt, msgtype, flag)

  23. An example of a msgq msqid_ds msqid msg_perm; msg_first; msg_last; msg_cbytes; msg_qbytes; msg_qnum; Link Type=200 Length=2 Data NULL Type=300 Length=3 Data Link Type=100 Length=1 data

  24. Using a message queue senders struct Msgqid_ds receivers P P msg msg msg P P

  25. Discussion of message queues • Msgq are more versatile than pipes and address some of their limitations, • Can transmit msgs as structured entities • Msg type can be used to specify e.g. priorities, urgency, designate recipient, • Can be used for small amount of data – expensive for large amounts • Kernel does not help with recipient specification, • Cannot broadcast msgs, • Allow selective retrieval of msgs by type, • STREAMS are now more popular for msg transfer

  26. Shared memory • A portion of physical memory that is shared by multiple processes. Process B Process A 0x30000 0x50000 0x50000 0x70000 Shared memory region

  27. Using the shared memory • shmid = shmget(key, size, flag) • addr = shmat(shmid, shmaddr, shmflag) • shmdt(shmaddr)

  28. Client/server with shared memory Shared memory client server kernel Output file Input file

  29. Implementation of shared memory struct shmid_ds { struct ipc_perm shm_perm; int shm_segsz; struct anon_map *shm_amp; ushort shm_nattch; … };

  30. Shared memory • Advantages – good for sharing large amount of data - very fast, • Limitation – no synchronization provided – applications must create their own • Alternative - mmap system call, which maps file into the address space of the caller,

  31. Discussion • IPC is similar to file system • Distinct name space • Unsuitable for distributed environment • difficult to agree on a common key key = ftok(char *pathname, int ndx) • Security: • If you can guess the key, you can r/w the resource.

More Related