320 likes | 439 Vues
This chapter delves into interprocess communication (IPC) facilities in operating systems, focusing on Universal IPC mechanisms and System V IPC. It covers methods for data transfer, sharing, event notification, and resource sharing among processes. Key IPC methods such as signals, pipes, and semaphores are explained in detail, alongside their applications and limitations. The chapter also explores the producer-consumer problem and how semaphores facilitate synchronization, addressing critical issues like deadlock detection and resource access management.
E N D
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 • Expensive • Limited: only 31 signals. • Signals are not enough.
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
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,
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()
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
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.
6.3. System V IPC • Common Elements • Key: resource ID • Creator: IDs • Owner: IDs • Permissions: r/w/x for g/owner/others
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
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
P/V Operations • P(wait): • s=s-1; • if (s<0) block(); • V(signal): • s= s+1; • if (s>=0) wake();
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
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); } }
Consumer Function void consumer(void) {while (TRUE){ wait(n); wait(s); remove_item(); signal(s); signal(e); } }
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
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; }
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 ]
Deadlock of semaphores lock S2 Proc A S1 Proc B lock
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
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)
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
Using a message queue senders struct Msgqid_ds receivers P P msg msg msg P P
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
Shared memory • A portion of physical memory that is shared by multiple processes. Process B Process A 0x30000 0x50000 0x50000 0x70000 Shared memory region
Using the shared memory • shmid = shmget(key, size, flag) • addr = shmat(shmid, shmaddr, shmflag) • shmdt(shmaddr)
Client/server with shared memory Shared memory client server kernel Output file Input file
Implementation of shared memory struct shmid_ds { struct ipc_perm shm_perm; int shm_segsz; struct anon_map *shm_amp; ushort shm_nattch; … };
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,
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.