Niti (threads)

Če te zanima kaj so niti, potem je boljše pogledat malo o tem kako operacijski sistemi delujejo (multi tasking) kot pa samo programiranje.

Niti ti omogočajo da tvoj program dela več stvari na enkrat ISTOČASNO.

Npr kakšen simpl program bi bil da ti reče: "Enter number:" in čaka na tvoj input. Če pa uporabiš nit na kakšni drugi funkciji lahko izvajaš tisto funkcijo v ozadju.

Alpa recimo če hočeš zadevo izvajat na več procesorjih na enkrat. Da ti recimo nek grafični program hitreje izračuna kako zadevo uporabi dva procesorja in prvi izračuna zgornjo polovico slike, drugi pa spodnjo.. istočasno. In je zadeva narejena veliko hitreje.

Ko delaš s threadi je potrebno paziti na istočasne dostope do zadev...

http://en.wikipedia.org/wiki/Thread_%28computer_science%29

http://www.codeproject.com/threads/#Threads

> Ker sta seda threda locena, se lahko ti vmes odlocis, da
> prekines program.

Khm! Tukaj je potrebno PRECEJ previdnosti, dva threada sta dalec od tega, da sta locena. Imata iste spremenljivke in dostop do istih delov pomnilnika v vecini primerov, but YMMV.

Dva threada pa teceta 'loceno', lahko tudi vsak na svojem procesu ali vcasih celo vsak na svojem racunalniku.

Kot je nekdo rekel YMMV, samo v večini OS, ki imajo (preemptive) večnitno procesiranje velja da:

1. Je nit osnovna enota izvajanja - vsi programi tečejo v vsaj eni niti (gl. 3)
2. Več niti je lahko grupiranih v proces, tim, aplikacijo karkoli se že imenuje v tvojem OS in si delijo naslovni prostor (zelo pomembno).
3. Tvoj program se začne v niti imenovani glavna nit (main thread), ki je bolj enaka od drugih, če gra ta, gre ponavadi še stack in kaj veš še kaj. To je pomebno, ker lahko neka nit načeloma teče dalje ne glede na kaj se je zgodilo z nitjo v kateri je bila ustvarjena - no, to je izjema.

Bistvo vsega je v 2. točki - niti tečejo v istem naslovnem prostoru. To ti po eni strani omogoča, da enostavno šibaš podatke naokoli brez nekih jakih IPC (inter-process comm) fint, kar je poanta vsega. Se pravi lahko uporabljaš vse kar si bil vajen doslej, glob. sprem, kazalce, vse je dostopno. Po drugi strani pa moraš ravno zaradi istega razloga še posebej paziti na možne probleme s sinhronizacijo in podobne razne... situacije.
Recimo, če v eni niti bereš ali spreminjaš nek skupen podatek (npr globalno spremenljivko). Moraš pod nujno najprej zakleniti s kakim semaforjem, narediti nekaj s podatki, nakar spet odkleniti. V nasprotnem primeru bo boš ali bral podatke, ki ti jih bo vmes druga nit pokvarila, ali pa boš ti tisti, ki boš kaj pokvaril. Na žalost nepravilno zaklepanje (napačen vrstni red) lahko vodi do deadlockov.

Možnost strela v nogo je bistveno večja kot pri programu v eni niti!!

Dober primer Microsoft! Lepo da si uporabil Sleep(), kot je treba. Tukaj je bolj, da se vidi kaj se dogaja, je pa to tudi na splošno edini pravi način za tratenje časa v katerikoli niti (tudi če imaš samo eno), ker s tem schedulerju poveš, da je toliko in toliko časa na voljo. Razno vrtenje v tesnih zankah (busy waiting) je Slaba stvar! Ima za posledico nabijanje uporabe CPU proti 100% in to..

Edino... a nisi mislil thread.Abort()? Ker po Suspend() nit še vedno obstaja, ustavi se samo izvajanje in lahko jo spet poženeš - se pravi je še vedno IsAlive()?

Ja to glede ustavljanja je res - čeprav članek govori za Suspend(), ki je lahko problematičen, poleg tega pa sploh ni nujno potreben. Abort() je bolj kot ne ok dokler zagotoviš, da počistiš točno tako kot bi to naredila nit, če bi se normalno končala. Skratka

tipičnov svoji nit delaš nekaj takega (v C#)
...
while (running) {
lock(this) {
// kritična sekcija
}
// Vse ostalo, kak Sleep() itd..
}
// nit se konča ob iztopu iz funkc.

Za ustavljanje potem niti nastaviš running je false...

Samo po drugi strani se pa ni dobro zanašati, da se je nit res ustavila! To je še posebno pomembno, ko končuješ... Tako da ena varianta bi bila tudi čisto na koncu:

thread.MyStopProc(); // varno nastavi running = false
Sleep(3000); // daj šanso
if thread.IsAlive()
// dosti heca!
thread.Abort();

To z while IsAlive() po mojem ni tako zelo fino, ker nit verjetno ne more priti iz stanja 'alive' v 'aborted' (killed) takoj, ampak šele v naslednjem ciklu, ko je na vrsti. Ves ta čas ti vmes na velko težiš sistemu, naj nit ukine v (dokaj tesni) while zanki... pomojem je Abort() dovolj, plus treba je poskrbeti, da se vse počisti kot bi se sicer normalno - če bi imel več niti s kakim zaklepanjem pa je tudi Abort() Slaba stvar - predvsem zato, ker grejo verjetno vsa zaklepanja v tisti niti stran...