[ -zombie- @ 17.05.2003. 16:34 ] @
ovako.. mene generalno ne zanima mnogo programiranje na ovako niskom nivou (osim možda menadžera virtuelne memorije i sličnih zajebancija), ali sam pomalo zaintrigiran da proširim svoje vidike.. ;)

1) razlika između fork-ova (tj procesa) i tredova.

ja sam prvenstveno win programer, pa nisam mnogo upoznat sa forkovanjem.. a i sa tredovima sam samo par puta praktično radio.. malo u javi, i malo u delphiju, (što je u suštini čist windows treding samo lepo wrapovan u klase kako to samo borland zna ;)

znači ne interesuju me veliki textovi, već nekoliko ključnih stavki u kojima se razlikuju..


2) zašto se ne pišu programi u ring0.

skoro na temi gde je objavljeno da je novi win uključio deo web servera u kernel (čitaj ring0), ja sam se zapitao zašto se to inače ne radi..

šta recimo sprečava apače, ili bilo koji drugi server/program da uradi isto.. koje su prednosti a koje mane tog postupka.. i kako sve to izgleda na linuxu (a i na win imam samo blagu predstavu kako to izgleda..)
[ tOwk @ 17.05.2003. 18:38 ] @
1. Ukratko, nit (thread) je „lakši“ proces. To znači da pokretanje niti oduzima manje procesorskog vremena, i da ima manje informacija vezanih za njih (zbog bržeg učitavanja).

Takođe, najčešće niti jednog procesa dele isti memorijski prostor, ali to zavisi od samog operativnog sistema i vrste niti.

2. ring0 = rad na samom procesoru do mile volje = neportabilno i nebezbedno

Loše napisan program u „ring0“ može da sruši čitav sistem. Za proces sa takvim privilegijama, bolje je biti siguran da on neće da brlja po tuđoj memoriji (pošto mu je apsolutno sva memorija na raspolaganju), pa čak može i samo jezgro da zezne. Uopšte, pisanje programa u ring0 je odstupanje od mehanizama zaštite koji su uvedeni upravo zbog loših programa. Znači, ako bismo sve programe pisali u ring0, to je vraćanje na W95 i DOS, i zanemarivanje svega što je naknadno došlo.

Prednosti koje program ima u „ring0“ je to što može svemu da pristupa neposredno: kešu operativnog sistema za fajlove, celoj memoriji, celom disku, svim uređajima (mrežnim karticama, itd.), tj. nema posrednika (API je vrsta posrednika, a svi znamo: što više posrednika, to duže traje postupak).

Apache, IIS i drugi serveri se mogu napraviti potpuno nezavisno od toga da li bilo kakva podrška postoji u jezgru. Tako, npr. Linux već 2–3 godine sadrži khttpd (Kernel HTTPd), koji istina retko ko koristi. On omogućava upravo to što MS sada ugrađuje u jezgro WS2003: brže služenje stranica.

On može da sarađuje sa bilo kojim drugim softverom (Apache, zar bi neko još nešto ;-), a radi na vrlo jednostavan način: ako stranica postoji na disku, pošalji je direktno (a to je onda veoma brzo), ako je potrebno dinamički nešto obraditi, onda prosledi zahtev serveru. MS je sigurno više toga preneo u jezgro kako bi postigao veće ubrzanje.


Takođe, problem ring0 je prisutan i sa drajverima. Npr. Linux je „monolitno“ jezgro, tj. drajveri rade sa istim privilegijama kao i samo jezgro. Zato, loš drajver može da radi na sistemu šta god poželi. Kod „mikrokernela“, drajveri su takođe izolovani, i sve što radi u ring0 je kod veličine neretko ispod 30kb. Tu je veliki problem brzina IPC-a (pošto se sve preko njega odvija), a istraživanja u ovoj oblasti razvoja operativnih sistema relativno kratko znaju za kvalitetna rešenja (rešenja koja su uporediva sa monolitnim jezgrima po pitanju brzine).

Ova vrsta dizajna je u mogućnosti da čak onemogući i sve vrste „prekoračenja bafera“, ali retke su implementacije koje idu do tih detalja. A samo zamislimo šta će nam nuditi sledeći „buffer overflow“ u Windows-u (najverovatnije ništa novo, pošto pretpostavljam da se i IIS dosad izvršavao sa dovoljnim privilegijama ;-)).
[ leka @ 10.06.2003. 17:17 ] @
Steta sto nema rejting sistema vise - sada bih dao cistu desetku ovom tekstu...
[ Ivan Dimkovic @ 10.06.2003. 18:18 ] @
Citat:

Znači, ako bismo sve programe pisali u ring0, to je vraćanje na W95 i DOS, i zanemarivanje svega što je naknadno došlo.


Mala digresija, ali koliko me pamcenje drzi, Win95 nije izvrsavao aplikacije u nultom prstenu. Medjutim, efektivno je bilo moguce vrlo lako srusiti sistem jer koncept vxd drajvera nije bio najbolji.
[ tOwk @ 10.06.2003. 18:26 ] @
Ivane, u pravu si: Windows programi u Windows-u 95 ne rade u ring0, ali si jednu stvar zaboravio: DOS programi su mogli neometano da se izvršavaju u Windows 95, pa sam na to mislio tada (zato i zajedno: DOS i Windows 95). Kasnije je i kroz sama izdanja '95-ice dodavano pomalo zaštite.

Mada, ako je i moje sećanje loše, pa ni DOS programi možda nisu baš mogli sve i svašta da rade u njemu. U svakom slučaju, mogli su da rade dovoljno da budu opasni (koliko DOS virusa se širilo i na tom izdanju Windows-a?).

Leko, hvala ;-)
[ Dragi Tata @ 10.06.2003. 19:06 ] @
Citat:
tOwk:

Takođe, najčešće niti jednog procesa dele isti memorijski prostor, ali to zavisi od samog operativnog sistema i vrste niti.


Ovo nisam znao. Koji operativni sistemi imaju niti koje ne dele isti memorijski prostor? U čemu je onda razlika između procesa i niti na takvim sistemima?
[ tOwk @ 10.06.2003. 19:38 ] @
Nemanja, to je čisto pitanje terminologije. Ne mogu da ti dam konkretan primer, ali znam da sam video par rasprava o tome šta je „thread“, iako je šire prihvaćeno da je i jedinstven adresni prostor njihova karakteristika (pošto je izmena adresnog prostora često jedna od „najskupljih“ operacija).

Isto to kažu i na: http://www.serpentine.com/~bos...s-faq/#5-5-Lightweight-process

Znači, ništa više do neusaglašene terminologije: „niti“ takve vrste su zapravo „lightweight process“ kako kaže comp.programming.threads FAQ.
[ mucky @ 10.06.2003. 19:39 ] @
Mislim da nema nikakve razlike, tj. na takvim sistemima su svi procesi teški (pravi) a ne laki (niti).
[ tOwk @ 10.06.2003. 19:43 ] @
Ne, ima razlike.

Usput, evo i konkretnog primera: „ultra-moderni“ mikrokernel L4, i njegova implementacija Hazelnut koristi upravo izraz „thread“ na ovaj način, ali razlikuje „global“ i „local“.

Pogledajte referencu na http://www.l4ka.org/projects/hazelnut/docs.php (strana 14).

PS. Pretpostavio sam da neki mikrokernel koristi ovakvu terminologiju, a L4 mi je drugi pao na pamet (prvo Mach, ali on razlikuje „task“ i „thread“) ;-)
[ Reljam @ 10.06.2003. 19:44 ] @
Jesi li siguran? Koji OSovi ne podrzavaju niti?
[ mucky @ 10.06.2003. 19:54 ] @
Ajde tovče sad lepo objasni šta si ti hteo reći sa tim svojim terminologijama :)

Po terminologiji koju ja znam, razlika između niti i procesa je u tome što proces
ima sopstveni PCB i memoriju (možda i još ponešto, ne znam) a niti su obično kreirane
od strane user-a (tj. nekog teškog procesa) i dele memoriju (prostor za mašinski kod
uvek, heap i prostor za globalne promenljive ponekad, a stack nikad).

A kako ta tvoja terminologija (ukratko) razlikuje procese?
[ tOwk @ 10.06.2003. 19:56 ] @
Reljam, postoji i pojam „user-space“ niti, tj. „raspoređivač niti“ (thread scheduler) se može implementirati i bez znanja jezgra, ukoliko ono nudi dovoljno mogućnosti (čini mi se da su tajmer i prekidi dovoljni; naravno, multiprogramiranje/multitasking/multiprocesiranje ili kako ko već to voli da zove se takođe može lepo iskoristiti [napomena u vezi terminologije: neko voli da koristi ova tri izraza za fino razlikovanje srodnih ideja, npr. „multiprogramiranje omogućava istovremeno izvršavanje više programa“, „multitasking je isto to za jednog korisnika“, itd.])
[ mucky @ 10.06.2003. 19:57 ] @
Reljam, ja ne znam tačno koji sistem ne podržava niti, ali suština je da
iako kernel ne pravi niti, teški procesi i dalje mogu da ih prave uz pomoć
sopstvenih biblioteka (ceo kod za upravljanje nitima generiše kompajler).
[ tOwk @ 10.06.2003. 20:03 ] @
Citat:
mucky:
Ajde tovče sad lepo objasni šta si ti hteo reći sa tim svojim terminologijama :)


Pa pogledaj referencu za L4 Hazelnut, šta ja da ti pričam ;-)

I to nije „moja“ terminologija.

Citat:
A kako ta tvoja terminologija (ukratko) razlikuje procese?

A zašto misliš da razlikuje? Kao što sam naveo „global threads“ ne dele memorijski prostor u L4 mikrokernelu, a „local threads“ ga dele, a za procese ti ljudi nikad čuli ;-)

No, kako smo mi (ljudi) „inteligentna bića“ i vršimo klasifikaciju pomoću osobina, a ne samo po nazivu (npr. pre ćemo reći da su „stolica“ i „naslon“ srodni, nego „naslon“ i „slon“), reći ćemo da je globalna nit u L4 analogna procesu u većini drugih operativnih sistema, a da je lokalna nit analogna samo niti.
[ Dragi Tata @ 10.06.2003. 20:11 ] @
Jasna mi je razlika između user-space niti kao pthreads na BSD-u i kernel niti ("lakih procesa") kao na Windows-u i Linux-u, a postoje i "hibridne niti" (Solaris) gde se više user niti mapira na jednu kernel nit. Međutim, u svim tim slučajevima niti dele memorijski prostor. Lično, uvek sam smatrao da je deljenje memorijskog prostora granica koja odvaja niti od procesa.
[ tOwk @ 10.06.2003. 20:22 ] @
Stvar je što si potpuno u pravu. Ali ne vodiš računa da se radi samo o terminologiji.

Znači, konceptualno, postoje niti i procesi. Niti odlikuje to što dele isti memorijski prostor, i „jeftinije“ je prebacivanje/izmena niti nego procesa.

Terminološki, neko će možda sve ovo uopštiti, i izabrati izraze:
— nit — putanja izvršavanja („thread of execution“), kod koji se izvršava, nezavisno od adresnog prostora i ostalih „peripetija“
— neka lakša nit — u primeru L4 mikrojezgra: „lokalna nit“
— neka teška nit — proces ili u primeru L4 mikrojezgra: „globalna nit“

Znači, u ovom slučaju imamo preslikavanje sa jedne terminologije na drugu:

proces ili nit — nit
nit — neka lakša nit
proces — neka teška nit

U nekim slučajevima je zgodnije ovako uopštiti procese i niti i koristiti jedan izraz za njih, a vi pogodite zašto sam ja baš ovakvo uopštavanje tražio među mikrokernelima ;-)
[ mucky @ 11.06.2003. 02:24 ] @
Čini mi se da se sve svodi na "nije šija neg je vrat" :)
[ PeraT @ 12.06.2003. 01:08 ] @
A mozda mozemo thread definisati kao jedinicu rada scheduler-a,
a proces kao program u izvrsavanju, a opet program kao tekst
instrukcija?

Nego kada se vec komplikuje ajd neka neko proba da definise
fiber!
[ Dragi Tata @ 12.06.2003. 01:51 ] @
Na Windows-u je fiber neka vrsta niti koja nije "preemptively scheduled" (prevedi, Danilo). Umesto da sistem brine o dodeljivanju CPU vremena, kao što je slučaj sa nitima, kod fiber-a sama aplikacija mora da brine o tome. Inače na Win16 i Mac (pre X-a) sistemima su niti imale istu ovu karakteristiku, pa ih niko nije zvao fiber-ima.
[ c00l_daem0n @ 12.06.2003. 15:23 ] @
Kako biste definisali šta je proces?
Da li je ovo tačna definicija: Proces je skup poslova (task) kojima proces upravlja.
[ PeraT @ 12.06.2003. 17:02 ] @
Citat:
Dragi Tata:
Na Windows-u je fiber neka vrsta niti koja nije "preemptively scheduled" (prevedi, Danilo). Umesto da sistem brine o dodeljivanju CPU vremena, ...


A sad jedno glupo pitanje: cemu ovakve stvari sluze?
[ Rapaic Rajko @ 12.06.2003. 17:12 ] @
Bogami ste bas zamrsili diskusiju. Ja mogu da pricam samo o Windows procesima i thread-ovima.
Dakle, pocecu od razlika izmedju njih, pa dokle stignem:

1) Prvo i prvo, nekakav owner-child odnos. Ako se ne varam, process moze 'sadrzati' vise thread-ova, u smislu da je on odgovoran za njihovo unistavanje, posto ih je on i kreirao (ja volim izraz 'lansirao'). Doduse, ovo nije sto posto tacno, jer postoji i nesto sto se zove CreateRemoteThread(), ali da ne ulazimo u tu pricu sad...
2) Prioriteti. Svakom thread-u mozete zasebno podici ili spustiti prioritet, i to ni na koji nacin ne utice na prioritet process-a kojem pripada. Drugim recima, prioritet thread-a je relativan u odnosu na prioritet process-a.
Ali ako promenite prioritet process-a, promenili ste i prioritet svih thread-ova koji njemu 'pripadaju'.
3) Child process-i. Process moze imati roditeljski odnos u jos jednom smislu: a to je da moze lansirati child procese, koji su (ako ne gresim) uslovljeni postojanjem owner process-a. (Mada mislim da ovo zadnje nije i obavezno).
Thread-ovi nemaju mogucnost ownership-a ni u kom obliku. Mislim, svaki thread moze lansirati proizvoljan broj process-a i thread-ova, ali ne moze biti 'owner' ni jednom od njih (bar ne onako kako to Windows uslovljava).
4) I da, cini mi se da sam video da postoji mogucnost kreiranja process-a bez osnovnog thread-a; mada nemam predstavu sta i kako, i da li uopste to nesto radi. Pod 'osnovnim' thread-om podrazumevam ThreadWindow objekat; znaci, nesto sto omogucava komunikaciju process-a sa ostatkom sveta (da, mislim na poruke).
S druge strane, ne mozete kreirati thread bez process-a, to jest svaki thread mora imati svog owner-a (process).

Nemam vise ideja.
Pozdrav

Rajko

P.S. Definicija process-a? Pa, recimo ovako nesto: process je ZAHTEV sistemu za dodelu procesorskog vremena...
[ Dragi Tata @ 12.06.2003. 18:24 ] @
Citat:

A sad jedno glupo pitanje: cemu ovakve stvari sluze?


E, na to pitanje neka ti odgovori MSDN:

"In general, fibers do not provide advantages over a well-designed multithreaded application. However, using fibers can make it easier to port applications that were designed to schedule their own threads."

Citat:
Process moze imati roditeljski odnos u jos jednom smislu: a to je da moze lansirati child procese, koji su (ako ne gresim) uslovljeni postojanjem owner process-a. (Mada mislim da ovo zadnje nije i obavezno).


Na Windows-u, child procesi nisu uslovljeni postojanjem parent procesa. Na nekim drugim operativnim sistemima jesu.

Citat:
4) I da, cini mi se da sam video da postoji mogucnost kreiranja process-a bez osnovnog thread-a; mada nemam predstavu sta i kako, i da li uopste to nesto radi. Pod 'osnovnim' thread-om podrazumevam ThreadWindow objekat; znaci, nesto sto omogucava komunikaciju process-a sa ostatkom sveta (da, mislim na poruke).
S druge strane, ne mozete kreirati thread bez process-a, to jest svaki thread mora imati svog owner-a (process).


Uh, ovde si malo zamrsio. Svaki proces mora da ima bar jednu nit. E, ako pod "osnovnom niti" podrazumevaš nit koja vrti message loop, onda je tačno da ne moraju svi programi da je imaju - konzolni programi i servisi je najčešće nemaju.
[ t3chX @ 12.06.2003. 20:52 ] @
Citat:
Dragi Tata:
Jasna mi je razlika između user-space niti kao pthreads na BSD-u i kernel niti ("lakih procesa") kao na Windows-u i Linux-u, a postoje i "hibridne niti" (Solaris) gde se više user niti mapira na jednu kernel nit. Međutim, u svim tim slučajevima niti dele memorijski prostor. Lično, uvek sam smatrao da je deljenje memorijskog prostora granica koja odvaja niti od procesa.


Upravo ... niti su "laksi" procesi koji dele isti memorijski prostor (i varijable) aplikacije iz koje su pokrenuti ... Tipican primer niti ? MS Word, auto-saving dokumenta u pozadini ... Takodje i pri pretrazivanju teksta, formatiranju paragrafa itd ...
Takodje (koliko sam ja upucen) niti su cesto koristene u Web serverima (Apache npr.) u kojima je najbitnija simultana interakcija sa vise korisnika ...

Ono sto bih zeleo da upitam je uloga semafora i mutex-a u "critical" regiji ... Recimo prevencija deadlock-ova ... Da li iko ima nekakav primer ?

Hvala
[ PeraT @ 13.06.2003. 15:23 ] @
HM, glavna uloga mutex-a je sprecavanje race_conditions-a,
a njihovim postavljanjem se samo povecava sansa za javljanje
deadlock-a (teorijski) (tako da od prevencije deadlock-ova nema nista),
jer cim se neki resurs proglasi "ne deljivim" zadovoljen je jedan od
4 neophodna i dovoljna uslova za deadlock.
[ tOwk @ 13.06.2003. 16:32 ] @
Citat:
t3chX:
Ono sto bih zeleo da upitam je uloga semafora i mutex-a u "critical" regiji ... Recimo prevencija deadlock-ova ... Da li iko ima nekakav primer ?


A šta kažeš na ideju da pokreneš novu temu sa ovim pitanjem, pa da sve ipak bude koliko-toliko izdvojeno i uređeno?
[ amel @ 27.07.2006. 08:10 ] @
Jedan vrlo poznat primjer sto se tice Deadlocks je

http://en.wikipedia.org/wiki/Dining_philosophers_problem