Uporabniku morajo biti na voljo primerni primitivi (na primer funkcijski klici) za delo z nitmi. Niti lahko realiziramo statično ali dinamično. V prvem primeru je število niti v nekem procesu določeno v fazi prevajanja. Vsaki niti je določen ločen sklad. Tak pristop je preprost a nefleksibilen. V drugem primeru niti nastajajo in se ukinjajo med izvajanjem programa. S primernim klicem definiramo tako glavni program niti (kazalec na primerno proceduro), kot tudi prostor za sklad, njeno prioriteto razvrąčanja itd.
Ker niti delujejo na istih (skupnih) podatkih, se poraja problem kritičnih sekcij. Uporabimo lahko tehniko mutex ali pa sinhronizacijo s pomočjo pogojnih spremenljivk. Muteksi so pravzaprav binarni semaforji z dvema stanjema ((ne)zaklenjen). Pogojne spremenljivke pa so podobne pogojnim spremenljivkam za sinhronizacijo monitorjev. Ključna razlika med obema principoma je, da so muteksi bolj primerni za kratkotrajno zaklepanje, pogojne spremenljivke pa za dolgotrajna čakanja na sprostitev vira.
Primerni paket za delo z nitmi (thread package) je lahko implementiran v uporabniškem ali v sistemskem prostoru. Oboje ponazoruje naslednja slika:
V prvem primeru jedro nič ne ve o nitih, ąe vedno upravlja enostavne, eno-nitne procese. Tak pristop je primeren predvsem za implementacijo na sistemih, ki nitkanja ne poznajo (primer starejše verzije UNIX). Niti tečejo nad posebnim modulom "run time", ki je pravzaprav zbirka procedur za rokovanje z nitmi. Preklop med nitmi je že na uporabniškem nivoju, kar je vsaj za razred hitrejše, kot če bi bil potreben prehod na nivo jedra. Dodatna prednost tega koncepta je, da ima vsak proces svoj algoritem razvrščanja procedur.
Po drugem principu upravlja z nitmi jedro.
Zato ne potrebujemo modula "run-time". Tabele za delo z nitmi se nahajajo
v jedru. Preklop med nitmi je precej bolj zahteven, saj blokiranje neke
niti dosežemo le z bolj zahtevnim sistemskim klicem. Zato pa lahko jedro
izbere za nadaljevanje poljubno nit (ne nujno od istega procesa). Implementacija
paketov za delo z nitmi na uporabniškem nivoju je sicer bolj učinkovita,
ima pa druge probleme. Nit v uporabniškem prostoru ne bi smela uporabljati
sistemskih klicev, saj to povzroči zaustavitev vseh niti danega procesa.
Druga slabost tega pristopa je tudi, da je delo drugih niti (v istem procesu)
pogojeno s "prostovoljnim" preklopom trenutno izbrane niti (podobno kot
pri korutinah). če niti krmili jedro, je enakopravnost vseh niti zagotovljena
z razvrščevalnikom.
Niti v Javi in njihova stanja
