Fakulteti i Shkencave Kompjuterike - TIT

SISTEMET OPERATIVE
DHE MENAXHIMI I SISTEMEVE

Kapitulli 3:
Proceset

Sistemet Operative dhe Menaxhimi i Sistemeve Prof. Ass. Dr. ArsimSusuri, 2018

Kapitulli 3: Proceset
 Koncepti i procesit
 Planifikimi i procesit
 Operacionet në procese
 Komunikimi ndërprocesor (IPC)
 Shembuj të sistemeve IPC
 Komunikimi në sistemet klient-server

3.2

1
Objektivat
 Të njoftojë me kuptimin e procesit – program në ekzekutim e
sipër, i cili formon bazën e kompjuterikës

 Të përshkruajë veçoritë e ndryshme të proceseve, përfshirë

këtu planifikimin, krijimin dhe përfundimin, dhe komunikimin

 Të hulumtojë komunikimin ndërprocesor përmes memories së

përbashkët dhe pasimit të mesazheve

 Të përshkruajë komunikimin në sistemet klient-server

3.3

Koncepti i procesit
 Një sistem operativ ekzekuton një shumëllojshmëri të programeve:
 Batch sistemet – punët
 Sistemet me ndarje kohore – programet e përdoruesit apo detyrat

 Libri përdor shprehjet punë dhe proces gati alternativisht

 Procesi – një program në ekzekutim e sipër; ekzekutimi i
proceseve duhet të përparojë në mënyrë sekuenciale
 Shumë pjesë
 Kodi i programit, i quajtur seksioni i tekstit
 Aktiviteti momental përfshirë këtu numëruesin e programit, regjistrat e
procesorit
 Steku që përmban të dhëna të përkohshme
 Parametra të funksioneve, adreat e kthimit, variablat lokale
 Seksioni i të dhënave që përmban variabëa globale
 Heapi që përmban memorie të shpërndarë në mënyrë dinamike gjatë
kohës së ekzekutimit

3.4

2
Koncepti i procesit ...
 Programi është entitet pasiv i ruajtur në disk (fajll të
ekzekutueshëm), procesi është aktiv
 Programi bëhet proces kur fajlli i ekzekutueshëm të ngarkohet në
memorie

 Ekzekutimi i programit i filluar përmes klikimeve GUI të miut,

komandës përmes emrit të fajllit, etj.

 Një program mund të jetë disa procese

 Merrni parasysh shumë përdorues që ekzekutojnë të njëjtin program

3.5

Procesi në memorie

3.6

3
Gjendja e procesit
 Gjatë ekzekutimi të procesit, ai e ndryshon

 new: Procesi është duke u krijuar

 running: Instruksionet janë duke u ekzekutuar

 waiting: Procesi është duke pritur për një ngjarje të ndodhë

 ready: Procesi është duke pritur që t’i bashkangjitet një procesori

 terminated: Procesi ka përfunduar ekzekutimin e tij

3.7

Diagrami i gjendjes së procesit

3.8

4
Blloku i kontrollit të proceseve (PCB)
Informacioni lidhur me secilin proces
(i quajtur edhe bllok i kontrollit të
detyrave)
 Gjendja e procesit – duke u ekzekutuar, pritur, etj.
 Numëruesi i programit – lokacioni i instruksionit
tjetër për ekzekutim
 CPU regjistrat – përmbajtjet e të gjitha regjistrave
në lidhje me proceset
 Informacioni për planifikim të procesorit, planifikim
të treguesve të rreshtave
 Informacion në lidhje me menaxhim të memories –
memoria e caktuar për procesin
 Informacioni llogaridhënë – procesori i përdorur,
koha kaluar prej fillimit, kufizimet e kohës
 Informacioni i gjendjes I/O – pajisjet të caktuara për
proces, lista e fajllave të hapur

3.9

Kalimi i procesorit prej njërit proces në tjetrin

3.10

5
Fillet
 Deri më tani, procesi ka një fill të ekzekutimit

 Paramendoni situatën me numërues të shumëfishtë të

programit për proces
 Lokacione të shumëfishta mund të ekzekutojnë njëkohësisht
 Fille të shumëfishta kontrolli -> fillet

 Duhet të kenë hapësirë për ruajtje të detajeve të filleve,

numërues të shumëfishtë të programeve në PCB

3.11

Reprezantimi i proceseve në Linux

Paraqitur përmes strukturës C task_struct

pid t_pid; /* process identifier */

long state; /* state of the process */
unsigned int time_slice /* scheduling information */
struct task_struct *parent; /* this process’s parent */
struct list_head children; /* this process’s children */
struct files_struct *files; /* list of open files */
struct mm_struct *mm; /* address space of this process */

3.12

6
Planifikimi i proceseve
 Maksimizo përdorimin e procesorit, ndërro shpejt proceset në
procesor për ndarje kohore

 Planifikuesi i proceseve përzgjedh mes proceseve në

dispozicion për ekzkeutim të ardhshëm në procesor

 Mirëmban rreshtat e planifikimit të proceseve

 Job queue –set i të gjitha proceseve në sistem
 Ready queue – set i të gjitha proceseve të pranishme në memorien
kryesore, të gatshme për ekzekutim
 Device queues – set i proceseve në pritje për një pajisje I/O
 Proceset migrojnë mes rreshtave të ndryshëm

3.13

Ready Queue dhe I/O Device Queue të ndryshëm

3.14

7
Paraqitja e planifikimit të proceseve

 Diagrami Queueing paraqet rreshtat, resurset, rrjedhat

3.15

Planifikuesit
 Planifikues afat-shkurtë (apo planifikues i procesorit) – selekton
cilat procese duhet të ekzekutohen në vijim dhe ia cakton procesorin
 Ndonjëherë i vetmi planifikues në sistem
 Planifikuesi afat-shkurtë invokohet shpesh (milisekonda)  (duhet të
jetë i shpejtë)
 Planifikues afat-gjatë (apo planifikues i punëve) – selekton cilat
procese duhet të sjellen në rreshtin e gatshëm
 Planifikuesi afat-gjatë invokohet jo aq shpesh (sekonda, minuta) 
(mund të jetë i ngadaltë)
 Planifikuesi afat-gjatë kontrollon shkallën e multiprogramimit
 Proceset mund të përshkruhen si:
 Procese të lidhura me I/O – shpenzojnë më tepër kohë në I/O sesa në
llogaritje, shumë hove të shkurta të procesorit
 Procese të lidhura me procesor – shpenzojnë më tepër kohë në
llogaritje; disa hove të gjata të procesorit
 Planifikuesi afat-gjatë përpiqet për kombinim të mirë të proceseve

3.16

8
Shtimi i planifikimit afat-mesëm
 Planifikuesi afat-mesëm mund të shtohet nëse shkalla e
programimit të shumëfishtë ka nevojë të zvogëlohet
 Largo procesin nga memoria, ruaje në disk, ktheje prapa nga disku
për të vazhduar me ekzekutim: swapping

3.17

Multitasking në sistemet mobile

 Disa sisteme mobile (p.sh., versione të hershme të iOS) lejojnë
ekzekutimin e vetëm një procesi, të tjerat janë të suspenduara

 Si pasojë e madhësisë së ekranit, interfejsi i përdoruesit i iOS ofron

 Një proces prioritar – i kontrolluar përmes interfejsit të përdoruesit
 Shumë procese në sfond – në memorie, duke u ekzekutuar, por jo në
ekran, dhe me kufizime
 Kufizimet përfshijnë, detyra të vetme, të shkurta, pranim të njoftimeve
për ngjarje, detyra specifike afat-gjata si p.sh., luajtja e audios

 Androidi ekzekuton proceset prioritare dhe ato në sfond, me pak

kufizime
 Procesi në sfond përdor një shërbim për të kryer detyrat
 Shërbimi mund të vazhdojë së ekzekutuari edhe nëse procesi në sfond
është i suspenduar
 Shërbimi nuk ka interfejs për përdorues, shfrytëzon pak memorie

3.18

9
Ndërrimi i kontekstit
 Kur procesori të kalojë në proces tjetër, sistemi duhet të ruajë
gjendjen e procesit të vjetër dhe të ngarkojë gjendjen e
ruajtur për procesin e ri përmes ndërrimit të kontekstit

 Konteksti i një procesi i paraqitur në PCB

 Koha e ndërrimit të kontekstit është overhead; sistemi nuk bën

punë të dobishme gjatë ndërrimit të kontekstit
 Sa më kompleks të jetë SO dhe PCB  aq më i gjatë ndërrimi i
kontekstit

 I varur nga koha me përkrahje harduerike

 Hardueri përkatës përkrah sete të shumëfishta të regjistrave për
procesor  kontekste të shumëfishta të ngarkuara njëkohësisht

3.19

Operacionet në procese
 Sistemi duhet të ofrojë mekanizma për :

 Krijim të proceseve

 Përfundim të proceseve

 Dhe kështu me radhë (si në vijim)

3.20

10
Krijimi i proceseve
 Procesi prind krijon procese fëmijë, të cilat në anën tjetër
krijojnë procese tjera, duke formuar një pemë të proceseve
 Në përgjithësi, procesi identifikohet dhe menaxhohet përmes
një identifikuesi të procesit (pid)
 Opcionet për përdorim të përbashkët të resurseve
 Prindi dhe fëmija ndajnë të gjitha resurset
 Fëmijtë ndajnë një nënset të resurseve të prindit
 Prindi dhe fëmijët nuk ndajnë resurset
 Opcionet për ekzekutim
 Prindi dhe fëmijët ezkeutohen në paralel
 Prindi pret deri sa fëmija të përfundojë

3.21

Pema e proceseve në Linux

init
pid = 1

login kthreadd sshd

pid = 8415 pid = 2 pid = 3028

bash khelper pdflush sshd

pid = 8416 pid = 6 pid = 200 pid = 3610

emacs tcsch
ps
pid = 9204 pid = 4005
pid = 9298

3.22

11
Krijimi i proceseve ...
 Hapësira adresore
 Duplikat i fëmijëve të prindit
 Fëmija ka një program të ngarkuar në të
 Shembujt UNIX
 Thirrja sistemore fork() krijon një proces të ri
 Thirrja sistemore exec() e përdorur pas një fork() për të
zëvendësuar thapësirën e memories së procesit me program
të ri

3.23

Programi C për të krijuar (forking) një proces të ri

3.24

12
Krijimi i procesit të ri përmes Windows API

3.25

Përfundimi i procesit
 Procesi ekzekuton deklaratën e fundit dhe më pas kërkonnga
sistemi operativ fshirjen përmes thirrjes sistemore exit()
 Kten të dhënat e statusit nga fëmija te prindi (përmes
wait())
 Resurset e procesit i rikthehen sistemit operativ

 Prindi mund të përfundojë ekzekutimin e proceseve fëmijë duke

përdorur thirrjen sistemore abort(). Disa arsye për ta bërë këtë:
 Fëmija ka tejkaluar resurset e shpërmdara
 Detyra e caktuar për fëmijën nuk është më e nevojshme
 Prindi po largohet dhe sistemet operative nuk lejojnë një
fëmijë të vazhdojë nëse prindi i tij përfundon

3.26

13
Përfundimi i procesit ...
 Disa sisteme operative nuk lejojnë ekzistimin e fëmijës nëse pridni i
tij ka përfunduar. Nëse procesi përfundon, atëherë edhe fëmija i tij
duhet të përfundojë.
 Përfundimi kaskadë. Të gjithë fëmijët, nipat/mbesat, etj. janë
të përfunduar.
 Përfundimi inicohet nga sistemi operativ.
 Procesi fëmijë mund të presë për përfundim të procesit fëmijë duke
përdorur thirrjen sistemore wait(). Thirrja e kthen informacionin
për gjendjen e statusit dhe pid-in e procesit të përfunduar
pid = wait(&status);
 Nëse nuk ka prind në pritje (nuk invokoi wait()) procesi është
zombie
 Nëse prindi përfundoi pa invokuar wait , procesi është orphan

3.27

Arkitektura multiprocesorike – Shfletuesi Chrome

 Shumë shfletues Interneti ekzekutoheshin si një proces i vetëm

 Nëse një faqe Interneti shkakton probleme, i tërë shfletuesi
mund të bllokohet apo rrëzohet
 Shfletuesi Google Chrome është multiproces me 3 lloje të
proceseve:
 Browser procesi menaxhon interfejsin e përdoruesit, diksut dhe
I/O të rrjetit
 Renderer procesi i paraqet faqet e Internetit, trajton HTML,
Javascript. Për secilën faqe të hapur krijohet një renderer i ri
 Ekzkeutohet në sandbox duke kufizuar I/O ët diskut dhe
rrjetit, duke minimizuar pasojat e keqpërdorimit të sigurisë
 Plug-in procesi për secilin lloj të plug-in

3.28

14
Komunikimi mes proceseve (IPC)
 Proceset brenda sistemit mund të jenë të pavarura apo kooperuse
 Procesi kooperues mund të ndikojë apo të ndikohet nga proceset
tjera, përfshirë këtu përdorimin e përbashkët të të dhënave
 Arsyet për proceset kooperuese:
 Shkëmbimi i informacionit
 Përshpejtimi i llogaritjes
 Modulariteti
 Lehtësia
 Proceset kooperuese kanë nevojë për komunikim mes proceseve
(IPC)
 Dy modele të IPC
 Memoria e përbashkët
 Pasimi i mesazheve

3.29

Modelet komunikuese
(a) Pasimi i mesazheve (b) Memoria e përbashkët

3.30

15
Proceset kooperuese
 Procesi i pavarur nuk mund të ndikojë apo të ndikohet nga
ekzekutimi i ndonjë procesi tjetër
 Procesi kooperativ mund të ndikojë ose të ndikohet nga ekzekutimi i
procesit tjetër
 Përparësitë e kooperimit të proceseve
 Shkëmbimi i informacionit
 Përshpejtimi i llogaritjes
 Modulariteti
 Lehtësia

3.31

Problemi prodhues-konsumator
 Paradigmë për procese kooperuese, procesi prodhues
prodhon informacion që konsumohet nga procesi
konsumator
 Buffer-i jo i lidhur nuk kufizon madhësinë e buffer-it

 Buffer-i i lidhur supozon që ekziston një madhësi fikse

e buffer-it

3.32

16
Zgjihja buffer i lidhur – memoria e përbashkët
 Të dhënat e përbashkëta
#define BUFFER_SIZE 10
typedef struct {
. . .
} item;

item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;

 Zgjidhja është korrekte, mirëpo mund të përdor vetëm elementet

BUFFER_SIZE-1

3.33

Buffer i lidhur - prodhuesi

item next_produced;
while (true) {
/* produce an item in next produced */
while (((in + 1) % BUFFER_SIZE) == out)
; /* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
}

3.34

17
Buffer i lidhur - konsumatori
item next_consumed;
while (true) {
while (in == out)
; /* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;

/* consume the item in next consumed */

}

3.35

Komunikimi mes proceseve – memoria e përbashkët

 Hapësirë e memories e shfrytëzuar bashkërisht mes

proceseve që dëshirojnë të komunikojnë

 Komunikimi është nën kontroll të proceseve të përdoruesve

e jo të sistemit operativ

 Çështje kryesore për të ofruar mekanizma që lejojnë

proceset e përdoruesve të sinkronizojnë veprimet e tyre
gjatë qasjes në memorie të përbashkët

3.36

18
Komunikimi mes proceseve – pasimi i mesazheve

 Mekanizëm për procese për të komunikuar dhe sinkronizuar

veprimet e tyre

 Sistemi i mesazheve – proceset komunikijnë me njëra tjetrën

pa pasur nevojë për variabla të përbashkëta

 IPC rrethina ofron dy operacione:

 send(message)
 receive(message)

 Madhësia e message është ose fikse ose variabile

3.37

Pasimi i mesazheve ...

 Nëse proceset P dhe Q dëshirojnë të komunikojnë ato duhet :
 Formojnë një link komunikues mes tyre
 Shkëmbejnë mesazhe përmes send/receive
 Çështje implementimi:
 Si janë të formuara linqet?
 A mund të lidhet një link me më shumë se dy procese?
 Sa linqe janë mes secilit çift të proceseve komunikuese?
 Cili është kapaciteti i linkut?
 A është madhësia e mesazhit, të cilin linku mund ta akomodojë,
fikse apo variabile?
 A është linku një-drejtimësh apo dy-drejtimësh?

3.38

19
Pasimi i mesazheve ...
 Implementimi i linkut komunikues
 Fizik:
 Memoria e përbashkët

 Bus-i harduerik
 Rrjeti

 Logjik:
 Direkt apo indirekt
 Sinkron apo asinkron
 Buffer-im automatik apo eksplicit

3.39

Komunikimi i drejtpërdrejtë
 Proceset duhet të emërtojnë njëra tjetrën në mënyrë eksplicite:
 send (P, message) – dërgon një mesazh te procesi P
 receive(Q, message) – prano një mesazhnga procesi Q

 Veçoritë e linkut komunikues

 Linqet formohen automatikisht
 Një link mund të asociohet me vetëm një çift të proceseve
komunikuese
 Mes secilit çift ekziston vetëm një link
 Linku mund të jetë një-drejtimësh, mirëpo zakonisht është dy-
drejtimësh

3.40

20
Komunikimi jo i drejtpërdrejtë
 Mesazhet drejtohen dhe pranohen nga mailbox-at (portet)
 Secili mailbox ka një ID unike
 Proceset mund të komunikojnë vetëm nëse najnë një mailbox

 Veçoritë e linkut komunikues

 Linqet formohen vetëm nëse ndajnë një mailbox
 Një link mund të asociohet me shumë procese
 Mes secilit çift mund të ekzistojnë disa linqe komunikuese
 Linku mund të jetë një-drejtimësh ose dy-drejtimësh

3.41

Komunikimi jo i drejtpërdrejtë ...

 Operacionet
 Krijo një mailbox të ri (port)
 Dërgo dhe prano mesazhe përmes mailbox-ave
 Shkatërro një mailbox

 Primitivet deinohen si:

send (A, message) – dërgo një mesazh në mailbox A
receive (A, message) – prano një mesazh mailbox A

3.42

21
Komunikimi jo i drejtpërdrejtë ...
 Ndarja e mailbox-it
 P1, P2, dhe P3 ndajnë mailbox-in A
 P1, dërgon; P2 dhe P3 pranojnë
 Kush e merr mesazhin?

 Zgjidhjet
 Lejo një ink të asocijohet me më së shumti dy procese
 Lejo vetëm një proces në kohë të ekzekutojë
operacionin receive
 Lejo sistemin të selektojë arbitrarisht pranuesin.
Dërguesi njoftohet kush ishte pranuesi

3.43

Sinkronizimi
Pasimi i mesazheve mund të jetë bllokues ose jo-bllokues
Bllokues konsiderohet të jetë sinkronizues
Dërgimi bllokues – dërguesi është i bllokuar deria sa të
pranohet mesazhi
Pranimi bllokues – pranuesi është i bllokuar deri sa mesazhi
të jetë në dispozicion
Jo-bllokues konsiderohet asinkron
Dërgimi jo-bllokues – dërguesi dërgon mesazhin dhe
vazhdon
Pranimi jo-bllokues – pranuesi pranon:
mesazh valid, ose
mesazh Null
Kombinime të ndryshme të mundshme
Nëse edhe dërgimi dhe pranimi janë bllokues, atëherë kemi
një takim (rendezvous)

3.44

22
Sikronizimi ...
 Prodhuesi-konsuatori bëhet i parëndësishëm

message next_produced;
while (true) {
/* produce an item in next produced */
send(next_produced);
}

message next_consumed;
while (true) {
receive(next_consumed);

/* consume the item in next consumed */

}

3.45

Buffer-imi
 Rresht i mesazheve të bashkangjtura me linkun

 Impementuar në një prej tri mënyrave

1. Zero kapacitet – pa mesazhe të rreshtuara në link.

Dërguesi duhet të presë për pranuesin (rendezvous)

2. Kapacitet i kufizuar – gjatësi e kufizuar e n mesazheve.

Dërguesi duhet të presë nëse linku është i plotë

3. Kapacitet i pakufizuar – gjatësi e pafund

Dërguesi kurrë nuk pret

3.46

23
Shembuj të sistemeve IPC Systems - POSIX

POSIX memoria e përbashkët

Procesi së pari krijon segmentin e memories së përbashkët
shm_fd = shm_open(name, O CREAT | O RDWR, 0666);
Po ashtu përdoret për të hapur një segment ekzistues për ta
ndarë
Përcaktohet madhësia e objektit
ftruncate(shm fd, 4096);
Tani procesi mund të shkruajë në memorien e përbashkët
sprintf(shared memory, "Writing to shared
memory");

3.47

Prodhuesi IPC POSIX

3.48

24
Konsumatori IPC POSIX

3.49

Shembuj të sistemeve IPC - Mach

 Komunikimi Mach është i bazuar në mesazhe
 Edhe thirrjet sistemore janë mesazhe
 Secila detyrë merr dy mailbox-a gjatë krijimit - Kernel dhe Notify
 Vetëm tri thirrje sistemore të nevojshme për transfer të mesazhit
msg_send(), msg_receive(), msg_rpc()
 Mailbox-at të nevojshëm për komunikim, krijohen përmes
port_allocate()
 Dërgimi dhe pranimi janë fleksibilë, p.sh., katër opcione nëse mailbox
full:
 Prit pa fund
 Prit më së shumti n milisekonda
 Kthe menjëherë
 Përkohësisht ruaj në cache një mesazh

3.50

25
Shembuj të sistemeve IPC – Windows
 Me orientim në pasim të mesazheve përmes rrethinës
së avansuar të thirrjeve lokale të procedurave (LPC)

 Funksionon vetëm mes proceseve në të njëjtin sistem

 Përdor porte (si mailbox-a) për të formuar dhe

mirëmbajtur kanale komunikuese

 Komunikimi funksionin si në vijim:

 Klienti hap një dorëz në objektin e portit konektues të
nënsistemit
 Klienti dërgon një kërkesës për koneksion
 Serveri krijon dy porte komunikuese private dhe e kthen dorëzën
në njërin prej klientëve
 Klienti dhe serveri përdorin dorëzën korrespeonduese të portit për
të dërguar mesazhe apo thirrje dhe për të dëgjuar përgjigjet

3.51

Thirrjet lokale të procedurave në Windows

3.52

26
Komunikimet në sistemet klient-server

 Socket-et
 Thirrjet e procedurave në largësi (RPC)
 Pipe-at
 Invokimi i metodave në largësi (RMI - Java)

3.53

Socket-et
 Një socket është e definuar si një pikë fundore komunikuese

 Vargu i IP adresës dhe porti – një numër i përfshirë në fillim të

paketit të mesazhit për të dalluar shërbimet e rrjetit në një host

 Socket-i 161.25.19.8:1625 i referohet portit 1625 në hostin

161.25.19.8

 Komunikimi përbëhet prej një çifti të socket-eve

 Të gjitha portet përfundi 1024 janë të mirënjohura, të

përdorura për shërbime standarde

 IP adresa e posaçme 127.0.0.1 (loopback) i referohet sistemit

në të cilin procesi ekzekutohet

3.54

27
Komunikimi i socket-eve

3.55

Socket-et në Java
 Tri lloje të socket-eve
 Me orientim në
koneksion (TCP)
 Pa koneksion (UDP)
 MulticastSocket
klasa – të dhënat mund
t’i dërgohen shumnë
pranuesve

 Konsiderojeni si server i
“takimit”:

3.56

28
Thirrja e procedurave në largësi (RPC)
 Thirrja e procedurave në largësi (RPC) abstragon thirrjet e
procedurave mes proceseve në rrejete kompjuterike
 Prapë përdor porte për të dalluar shërbimet

 Stub-et – proxy në anën e klientit për procedurën aktuale në

server

 Stub-i në anën e klientit lokalizon serverin dhe i ruan

parametrat

 Stub-i në anën e serverit e pranon këtë mesazh, i shpaketon

parametrat e ruajtur, dhe performon procedurën në server

 Në Windows, kodi i stub-it kompajlohet nga specifikat e

shkruajtura në Microsoft Interface Definition Language
(MIDL)

3.57

Thirrja e procedurave në largësi (RPC) ...

 Përfaqësimi i të dhënave i trajtuar nga formati External Data
Representation (XDL) prë t’u përballur arkitektura të
ndryshme
 Big-endian dhe little-endian

 Komunikimi në largësi ka më shumë skenarë të dështimit se

sa komunikimi lokall
 Mesazhet mund të dërgohen vetëm njëherë në vend të
më së shumti njëherë

 SO zakonisht ofron një shërbim takimi (matchmaker) për të

lidhur klientin dhe serverin

3.58

29
Ekzekutimi i RPC

3.59

Pipe-at
 Luan rolin e përçuesin që mundëson komunikimin mes dy
proceseve

 Çështjet:
 A është komunikimi një-drejtimësh apo dy-drejtimësh?
 Në rast të komunikimit dy-drejtimësh, a është half-duplex apo full-
duplex?
 A duhet të ekzistoë relacion (p.sh., prind-fëmijë) mes proceseve
komunikuese?
 A mund të përdoren pipe-at nëpër rrjet kompjuterik?

 Pipe-at e zakonshëm – nuk mund t’iu qasemi nga jashtë

procesit i cil i ka krijuar.
 Zakonisht, një proces prind krijon një peipe dhe e përdorë për të
komunikuar me procesin fëmijë të cilin e ka krijuar

 Pipe-at e emërtuar – mund të qasen pa pasur relacion prind-

fëmijë.
3.60

30
Pipe-at e zakonshëm
Pipe-at e zakonshëm lejojnë komunikim në stilin e zakonshëm
prodhues-konsumator
Prodhuesi shkruan në njërin skaj (skaji write-end i pipe-it)
Konsumatori lexon nga skaji tjetër (skaji read-end i pipe-it)
Prandaj, pipe-at e zakonshëm janë një-drejtimësh
Ka nevojë për relacionin prind-fëmijë mes proceseve komunikuese

Windows i quan këta pipe-a anonimë

3.61

Pipe-at e emërtuar
 Pipe-at e emërtuar janë më të fuqishëm se pipe-at e zakonshëm

 Komunikimi është dy-drejtimësh

 Nuk është i domosdoshëm relacioni prind-fëmijë mes proceseve

komunikuese

 Disa procese mund të përdorin pip-in e emërtuar për komunikim

 Ofron në të dyja sistemet UNIX dhe Windows

3.62

31
 Fundi i Kapitullit 3

Sistemet Operative dhe Menaxhimi i Sistemeve Prof. Ass. Dr. ArsimSusuri, 2018

32