[so] [Tema 4]so_fork & friends

[Razvan Crainea]

Salut, Radu!

1. Într-adevăr, după fiecare operație ar trebui apelat scheduler-ul. Dacă
acesta determină că trebuie preemptat, ar trebui să renunțe la procesor și
să treacă în coada READY.
2. Da, ideea ta este bună. so_fork ar trebui să fie un fel de wrapper peste
pthread_create, unde poți stoca ce variabile vrei. so_fork este considerată
și ea o instrucțiune, deci poate fi preemptată. Totuși regulile
planificatorului trebuie să fie repectate.
3. Ești pe drumul cel bun :).
4. Da.

Spor!


2013/5/4 Radu Stancu <stancumradu at gmail.com>

> Salut,
>
> Am si eu mai multe nelamuriri la tema 4.
> 1. Din cate observ, trebuie sa facem re-schedule la fiecare final de
> functie, just in case se termina cuanta de timp.Este corect asa?
> 2. Cum fac un thread abia creat sa astepte randul sau? Ma gandeam sa fac
> similar cu wait, sa am o variabila de conditie care sa blocheze threadul,
> dar ideea e unde o pun? Fac o functie separata care sa fie apelata de
> pthread_create si in ea pun variabila? Daca fac asa, se blocheaza so_fork
> si
> voi avea probleme la testare, de exemplu de la testul 4 in sus. Cel putin
> asa banuiesc ca se intampla.
> 3. Dupa trezirea din wait, daca threadul trebuie sa mai astepte sa ii vina
> randul, unde fac asta? Pun in wait sa astepte iar dupa o variabila de
> conditie globala si ramane blocat in wait? (practic cand este planificat,
> iese din wait si executa in continuare)
> 4.Pot face broadcast in signal si sa blochez threadurile ca in punctul 3?
>
> Momentan doar atat. Daca cineva are idei sau intrebari, feel free to
> contribute
>
>
> _______________________________________________
> http://ocw.cs.pub.ro/courses/so/info/lista-discutii




-- 
Răzvan Crainea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20130504/87aa05c7/attachment.html>