320 likes | 431 Vues
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
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.