1. Scopul lucrării

Lucrarea de faţă prezintă o modalitate de comunicare între procese folosind o tehnică valabilă în orice versiune UNIX şi anume prin canale de comunicaţie, numite şi conducte sau pipe. În lucrare sunt prezentate atât conductele unidirecţionale cât şi cele bidirecţionale precum şi modul în care se poate evita blocarea (deadlock) proceselor.

2. Consideraţii teoretice

Pipeurile sunt canale de comunicaţie între procese, prin care informaţiile sunt transferate de la un proces la altul printr-un mecanism FIFO.

Canalele de comunicaţie sunt familiare utilizatorilor sistemului UNIX ca facilitate a interpretorului de comenzi shell. De exemplu, pentru a tipări o listă ordonată a utilizatorilor ce au deschis o sesiune de lucru în sistem se foloseşte comanda:

who | sort | pr

Există trei procese conectate prin două conducte. Fluxul datelor este de la stânga la dreapta.

Cu ajutorul conceptului de pipe-line, rezolvarea unei probleme mari se face descompunând-o în probleme mici, cu avantajele corespunzătoare:

• scrierea programelor se face fără dificultate;
• testarea şi punerea la punct a programelor se face uşor;
• posibilitatea lucrului în echipă.

2.1. Apelul sistem PIPE

Crearea unui fişier pipe se face cu ajutorul funcţiei de sistem pipe, a cărei interfaţă este următoarea:

#include <unistd.h>

int pipe ( int pfd[2]);

Returnează 0 în caz de succes, (-1) în caz de eroare.

Argumentul pfd este un tablou cu două elemente, care după execuţia funcţiei va conţine:

• descriptorul de fişier pentru citire pfd[0] şi
• descriptorul de fişier pentru scriere pfd[1].

În caz de eroare variabila errno indică eroarea apărută.

Fig.1. Pipe între două procese.

Citirea şi scrierea în fişiere pipe se face conform algoritmului FIFO (primul intrat, primul ieşit). Sincronizarea între procesele care scriu în fişier şi cele care citesc din fişier se face pe principiul producător/consumator, care constă în următoarele:

a) Un proces de scriere ("producător") va putea scrie în fişier dacă acesta nu este plin. În caz contrar, procesul de scriere va fi întârziat (blocat) până când un proces de citire ("consumator") ia date din fişier.

b) Un proces de citire ("consumator") va putea prelua date din fişier dacă acestea există. În caz contrar, procesul de citire ("consumator") va fi întârziat (blocat) până când un proces de scriere ("producător") nu a depus date în fişier.

În cazul în care se cer mai multe date decât există se preiau câte există.

Caracteristicile fişierelor pipe sunt următoarele:

a) Dimensiunea unui fişier pipe este limitată la maximum 10 blocuri. Gestionarea blocurilor se face ca într-un buffer circular sau coadă circulară. Adresarea blocurilor de date se face direct (acces rapid la ele).

b) Dacă s-au citit date din fişier, asupra lor nu se mai poate reveni. Sistemul de gestionare a fişierelor menţine în tabela fişierelor adresa de citire şi scriere în intrări diferite.

c) Pentru a asigura respectarea algoritmului FIFO, la un fişier pipe pot avea acces numai procesul care l-a creat şi descendenţii săi. În mod normal pipe-ul este creat de un proces care a apelat fork, şi pipe-ul este folosit între procesul părinte şi fiu. Prin apelul fork, intrările în tabela fişierelor sunt partajate între părinte şi fiu. De aici rezulta concluzia, ca prin fişiere pipe pot comunica procesul părinte cu procesele fiu sau procese care au un strămoş comun.

d) într-un fişier pipe nu este posibil accesul direct, ci numai secvenţial. Acest lucru este impus pentru ca datele să fie preluate strict în ordinea depunerii lor. Ca urmare, un utilizator nu poate modifica deplasamentul într-un fişier pipe cu funcţia de sistem lseek.

e) Dacă un proces încearcă să scrie într-un fişier pipe o înregistrare de dimensiune mai mare ca spaţiul liber din fişier, sistemul de gestionare a fişierelor procedează astfel: scrie date până umple spaţiul gol, apoi blochează procesul. Dacă între timp a avut loc o citire, procesul va fi deblocat. Dar s-ar putea ca un alt proces de scriere să fie activat înaintea celui care a fost blocat. De aceea s-ar putea crea interclasări de date scrise de procese diferite. Acest lucru trebuie evitat printr-o sincronizare corectă între procese.

f) Operaţiile asupra unui fişier pipe sunt următoarele:

• crearea fişierului cu funcţia de sistem pipe;
• citirea/scrierea cu funcţiile de sistem read/write;
• setarea indicatorului O_NDELAY prin funcţia de sistem fcntl, care are următorul efect: dacă funcţiile de sistem read sau write nu pot fi completate, procesul care le-a apelat nu va fi blocat până la îndeplinirea totală a sarcinii de scriere sau citire, ci funcţiile de read/write se vor termina returnând zero.
• închiderea fişierului cu funcţia de sistem close;
• ştergerea fişierului, mai precis a inode-ului corespunzător; aceasta se face de către sistemul de gestionare a fişierelor când numărul de referiri din inod devine zero.

Pentru a duplica un descriptor de fişier se folosesc apelurile sistem dup şi dup2:

#include <unistd.h>

int dup( int fd);

int dup2( int fd, int nfd);

Returnează descriptorul nou în caz de succes, -1 în caz de eroare.

Se creează un descriptor nou pe lângă descriptorul de fişier existent. Descriptorul de fişier returnat de dup este numărul de descriptorul cel mai mic disponibil. Folosind acest lucru se poate redirecta cu uşurinţă intrarea şi /sau iesirea standard. Asupra acestui aspect vom reveni pe parcurs.

Folosind dup2, se poate specifica valoarea descriptorului nou prin argumentul ndf. Dacă fd era deschis acesta este închis.

Noul descriptor returnat referă aceeaşi intrare în tabela fişierelor ca şi vechiul, ceea ce semnifică că există un pointer în fişier unic şi aceleaşi drepturi de acces asupra fişierului pentru fiecare descriptor. Apelul eşuează dacă argumentul este eronat (nu este deschis) sau dacă sunt deja 20 de descriptori deschişi.

Pentru compatibilitate cu versiunile mai vechi se poate folosi şi apelul fcntl, cu argumentele precizate astfel:

nfd=fcntl( fd, F_DUPFD, x);

Apelul asigură că descriptorul returnat este mai mic sau egal cu x.

Efectul apelurilor sistem de I/E asupra acestor descriptori este însă diferit faţă de efectul lor asupra unui descriptor de fişier obişnuit. Din acest motiv se redescriu aceste apeluri sistem:

Write: datele sunt scrise în conducta în ordinea în care ele sosesc. Capacitatea unei conducte variază funcţie de versiunea UNIX, dar de regulă ea nu este mai mica decât 4096 octeţi. Dacă un canal este plin apelul write se blochează până un alt proces goleşte pipe-ul prin citire. Nu există scrieri parţiale; apelul write nu revine decât după o scriere completş (excepţie fac situaţiile în care fanionul O_NDELAY a fost poziţionat prin apelul fcntl). Singurul mod de pune un sfârşit de fişier într-un canal este de a închide descriptorul de scriere.

Read: datele sunt citite din conducta în ordinea în care ele sosesc. Odată citită o dată nu se poate reciti sau repune în conductă. Un apel read revine chiar dacă nu s-au găsit toţi octeţii, valoarea returnată fiind numărul de octeţi efectiv citiţi. Dacă conducta este goală citirea se blochează până când o dată devine disponibilă pentru citire (excepţie face poziţionarea fanionului O_NDELAY). În cazul în care pfd[1] este închis valoarea returnată de read este 0, aceasta fiind modul prin care se semnalează procesului cu care se comunică, sfârşitul de fişier.

Close: semnifică pentru conducte mai mult decât disponibilizarea descriptorului. Dacă se închide pfd[1] aceasta semnifică şi sfârşit de fişier pentru cel care citeşte conducta, iar dacă se inchide pfd[0], scrierea în descriptorul de fişier va produce eroare. În acest caz se generează semnalul SIGPIPE ("Write on a pipe not opened for reading" - a se vedea lucrarea cu semnale).

Fstat: apelul e puţin utilizat în cazul conductelor. Apelul întoarce ca rezultat numărul de octeţi din conducta, dar acest lucru este puţin important. Acest apel este însă util pentru a determina dacă un descriptor de fişier corespunde sau nu unui pipe, prin testarea numarului de legături (links). O conductă se identifică prin valoarea 0 a numărului de legături.

Open, Creat, Lseek: nu se folosesc în cazul conductelor din raţiuni evidente.

Pipeul este folosit pentru comunicarea între două procese, aşa încât nu există nici o raţiune în a folosi acest mecanism în cadrul unui proces. În acest caz este posibilă blocarea procesului (deadlock) dacă în conducta se scriu mai mulţi octeţi decât capacitatea conductei.

Pipe-urile folosesc acelaşi mecanism de buffer cache care se foloseşte şi pentru fişierele de pe discuri. Scrierea unui bloc (uzual de 512 octeţi) este o operaţie atomica, aceasta însemnând ca scrierea unui bloc implică o citire corespunzătoare tot de un bloc (dacă se doreşte). Oricum, dacă nu se scriu blocuri complete, citirea nu este afectată, deoarece apelul read citeşte blocuri parţiale. Acest lucru nu se întâmplă însă dacă scrierea în pipe este mai rapidă decât citirea.

2.1. Conducte unidirecţionale

Pentru ca între doua procese să se poată stabili un pipe unidirectional este necesar ca ambele procese să cunoască descriptorii asociaţi pipe-ului. Două procese deja create nu pot fi conectate printr-un pipe. Pipe-ul trebuie creat intr-unul din procese înaintea creării celui de-al doilea proces, pentru ca astfel ultimul să moştenească descriptorii de fişier ai pipe-ului. Rezultă că doua procese care pot comunica prin pipe trebuie să fie în relaţia părinte-fiu sau două procese cu strămoş comun; pipe-ul trebuie creat în primului proces. În practica acest lucru constituie o limitare serioasă, deoarece dacă un proces dispare nu există nici o cale pentru a-l recrea şi reconecta la conducta sa. Procesul rămas trebuie terminat şi pipe-ul trebuie recreat.

Este important de remarcat ca pipe-ul unidirectional, de tipul celor create de shell, nu poate conduce niciodată la blocare.

Pentru a interconecta doua procese prin pipe se pot urma paşii:

1) Primul proces construieşte pipe-ul prin apelul pipe;

2) Se creează procesul fiu prin apelul fork;

3) În procesul fiu se închide descriptorul de scriere şi se fac eventual alte pregătiri;

4) Se executa programul fiului (apelul exec);

5) În părinte se închide descriptorul de citire;

6) Dacă există şi un al doilea fiu, care se doreşte să scrie în pipe, se creează şi execută programul corespunzător lui;

7) Procesul părinte scrie datele în pipe.

O raţiune pentru care apelurile fork şi exec nu au fost contopite într-un unic apel sistem este ca între ele să se poată face unele prelucrări (vezi pasul 3) către altfel, făcute în alta parte, ar fi mult mai costisitoare.

Pentru a elimina transmiterea descriptorului de fişier ca argument în linia de comanda proiectanţii sistemului UNIX propun o soluţie mult mai elegantă. Ea are la bază ideea ca multe programe îşi iau datele de intrare din intrarea standard, care are asociat descriptorul 0 şi scriu datele la ieşirea standard care are asociat descriptorul 1. Se conturează ideea ca pentru a conecta două comenzi în maniera de lucru shell trebuie să asociem pipe-ului aceşti doi descriptori. Prin simpla închidere a celor doi descriptori anterior menţionaţi înainte de apelul pipe nu avem certitudinea ca pipe-ul creat va avea asociat aceşti doi descriptori.

Apelul dup duplică un descriptor de fişier astfel încât după apel fişierul care are asociat descriptorul fd să poată fi accesat şi prin descriptorul întors de dup. În cazul de faţă, prin duplicarea descriptorului se doreşte să se obţină un descriptor "particular" care să răspundă mai bine cerinţelor apelantului. Particularitatea sa rezultă din faptul că apelul dup returnează descriptorul cu număr minim dintre cei neutilizaţi. Aceasta înseamnă că dacă înainte de apelul dup, am închis descriptorul 0, apelul dup va întoarce cu siguranţă 0. În mod identic dacă s-a închis descriptorul 1, descriptorul 0 fiind utilizat, apelul dup va întoarce 1. În caz de eroare, valoarea returnată este -1.

Acest lucru permite obţinerea descriptorului 0 ca descriptor de citire din pipe şi descriptorului 1 ca descriptor de scriere în pipe.

2.2. Conducte bidirecţionale

O conducta bidirecţională este un canal de comunicaţie între două procese în care fluxul de date se desfăşoară în ambele direcţii.

Două procese interconectate printr-o conducta aveau acţiuni clare şi distincte: unul scrie în conductă, iar celălalt citeşte. Este tentant să se conecteze două procese care ambele încearcă să citească şi să scrie. Din păcate această soluţie nu funcţionează deoarece nu există sincronizare între procese. Se poate întâmpla, ca citind dintr-o astfel de conductă, să se citească informaţia care anterior a fost scrisă pentru a fi transmisă spre celălalt proces, dar care însă nu a ajuns să fie citită de acesta. Apar astfel blocaje, deoarece al doilea proces poate să ajungă în situaţia de-a aştepta la infinit o informaţie care nu mai vine. Reuşita unui pipe bidirecţional este dependentă de ordinea în care procesele partajează unitatea centrala. Se recomandă în locul folosirii conductei bidirecţionale a două conducte unidirecţionale. Descriptorii de fişiere blocati sunt tot doi pentru fiecare proces, ceilalti doi putând fi închisi după cum s-a văzut în exemplele anterioare.

De exemplu, să considerăm un program care citeşte datele din fişierul data şi foloseşte filtrul sort pentru a le ordona alfabetic. În final, datele sortate sunt afişate. Aceasta înseamnă ca unul din procese scrie datele nesortate în conductă, iar celălalt le citeşte, le sortează şi le rescrie în conductă pentru ca primul proces să le citească sortate. Rezolvarea problemei în această maniera oferă însă un rezultat surprinzător. Datele nu sunt sortate şi programul se blochează ("agaţă"). Cauza este nesincronizarea între procese. După ce datele nesortate au fost scrise în pipe de procesul părinte, acesta începe să citească pipe-ul, presupunând ca deja citeşte rezultatul aplicării filtrului sort. Dar acest lucru este făcut înaintea aplicării filtrului şi astfel se citesc înapoi datele nesortate.

Procesul fiu, care executa filtrul, începe să-şi citească intrarea standard, care este goală din moment ce procesul părinte tocmai a citit tot. Indiferent dacă intrarea e plină sau goală, sort se blochează în aşteptarea unui sfârşit de fişier, care este generat la închiderea descriptorului de scriere. Cu siguranţă, procesul ce scrie datele va închide acest descriptor, dar procesul fiu îl are încă deschis, deoarece el trebuie să scrie datele acolo. Ca atare, fiul a fost blocat.

În general, un filtru implicat în scrierea şi citirea unei conducte ajunge la blocaj. În cazul în care datele ce necesită a fi sortate nu determină umplerea conductei, punerea în aşteptare a procesului părinte până la terminarea procesului fiu este o soluţie comoda. Dacă această alternativa nu satisface rămâne folosirea a două conducte cu trafic unidirecţional. Rezolvarea corectă a acestei probleme este prezentată în aplicaţia 3.3.

Blocajul este posibil şi cu doua conducte în cazul în care procesele se blochează pe apeluri write. Aceasta se produce când ambele conductele devin pline, procesele nefăcând suficiente citiri din ele. Fiecare caz trebuie analizat cu grijă pentru a preveni blocajul.

3. Mersul lucrării

3.1. Se considera următorul programul:

#include <stdio.h>

char msg1[]="abcdefghij";

char msg2[]="1234567890"; /* funcţie de mesaje */

main()

{

char buf[128];

int pfd[2], pid;

pipe( pfd);

if (( pid=fork())==0) {

printf("Fiul transmite: %s\n", msg1);

write( pfd[1], msg1, 11);

read( pfd[0], buf, 13);

printf("Fiul receptat: %s\n", buf);

exit(1);

else {

read( pfd[0], buf, 11);

printf("Tatal receptat: %s\n", buf);

write( pfd[1], msg2, 13);

printf("Tatal transmite: %s\n", msg2);

}

}

Explicaţi funcţionarea acestui program. Ce probleme pot să apară ?

3.2. Să se scrie un program care afişează conţinutul fişierului primit ca argument în linia de comandă. Programul afişează conţinutul fişierului pagină cu pagină.

#include <sys/wait.h>

#include "hdr.h"

#define DEF_PAGER "/usr/bin/more"

main( int argc, char *argv[])

{

int pfd[2], n;

pid_t pid;

char buf[MAXLINE], *pager, *arg;

FILE *fp;

if ( argc !=2 )

err_quit("Utilizare: a.out <path>\n");

err_sys("Eroare pipe");

err_sys("Eroare fopen %s", argv[1]);

case 1: err_sys("Eroare fork");

case 0: /* fiul citeste */

n=strlen( buf);

if ( write( pfd[1], buf, n) != n)

err_sys("Eroare write");

if ( ferror( fp))

err_sys("Eroare ferror");

if ( waitpid( pid, NULL,0) < 0)

err_sys("Eroare waitpid");

}

}

3.3. Să se scrie un program care citeşte datele dintr-un fişier, primit ca argument în linia de comandă şi foloseşte filtrul sort pentru a le ordona alfabetic. În final, datele sortate sunt afişate.

/*

A se compila cu: gcc o fsort 4_7.c err.o

*/

#include <stdio.h>

#include "hdr.h"

void fsort( char *);

int main( int argc, char *argv[])

{

if ( argc < 2)

err_quit("Utilizare: fsort <nume.txt>\n");

}

void fsort( char *path)

{

int pfdout[2], pfdin[2], fd, nr;

char buf[512];

if ( pipe( pfdout) < 0 || pipe( pfdin) < 0)

err_sys("Eroar pipe");

case 1: err_sys("Eroare fork");

case 0:

4.1. Care sunt problemele care apar dacă procesul fiu nu cunoaşte descriptorul pentru pipe ?

4.2. Ce se întâmplă dacă există un singur fişier pipe la aplicaţia 3.3. ?

4.3. Să se implementeze apelul sistem dup folosind apelul sistem fcntl.

4.4. Să se scrie un program în care se creează două procese în relaţia părinte fiu. Procesul părinte scrie un şir în pipe, iar procesul fiu afişează conţinutul pipe-ului folosind comanda unix cat.

4.5. Să se scrie folosind un pipe rutine de sincronizare pentru procese aflate în relaţia părinte-fiu.

4.6. Un filtru e numit coproces când acelaşi program îşi generează intrarea şi îşi citeşte ieşirea. Să se scrie un astfel de program care citeşte două numere din intrarea standard şi scrie suma lor la ieşirea standard.

4.7. Să se scrie un program care apelează coprocesul de la problema anterioară. Programul citeşte două numere din intrarea standard, le transmite coprocesului care calculează suma lor şi afişează acest rezultat la ieşirea standard.

4.8. Folosind apelurile sistem pipe, fork şi exec să se scrie programul care echivalează linia de comanda a shelului:

comanda1 | comanda2

Cele două comenzi se citesc ca argumente din linia de comandă.

4.9. Să se generalizeze problema 4.6. pentru linii de comanda de forma:

cd1 arg1 arg2 ... | cd2

Testarea programul se poate realiza prin comenzi de forma:

a.out cat 4_1.c 4_2.c pipe more

a.out ls -l /root pipe more

a.out cat 4_1.c pipe sort

4.10. Să se implementeze un editor interactiv folosind editorul ed şi apelul fork şi pipe. Ce probleme apar ?