[so] [Tema 4][Linux] Necesitate stare NEW si sincronizare
Adrian Pop
popadrian1996 at gmail.com
Tue May 15 23:21:29 EEST 2018
Salut!
Multumesc mult pentru raspunsuri!
O seara frumoasa!
Adi
2018-05-15 23:00 GMT+03:00 Razvan Crainea <razvan.crainea at gmail.com>:
> Salut, Adrian!
>
> Găsești răspunsurile mele inline.
>
> Numai bine,
> Răzvan
>
> On Tue, May 15, 2018 at 8:46 PM Adrian Pop via so <so at cursuri.cs.pub.ro>
> wrote:
>
>> Salutare!
>> Este necesara ca un thread (structura custom care simuleaza un thread) sa
>> treaca si prin starea NEW, sau la initializare, obiectul poate fi returnat
>> avand direct starea READY? Nu gasesc ceva specific ce thread-ul ar trebui
>> sa execute ca sa fie in procesul 'de admisie' si astfel sa fie necesara
>> ambele stari. Am doua variante (functionale amandoua) pentru acest proces,
>> insa vreau sa ma asigur ca vreunul dintre ele nu este incomplet, nu
>> respecta anumite reguli sau este ne-intuitiv.
>>
>
> Dacă nu găsești un caz pentru care să fie nevoie de starea NEW, atunci nu
> este nevoie să o folosești - depinde strict de modul în care implementezi
> tu.
>
>
>> 1. Am un semafor pentru intreg contextul scheduler-ului. Structura se
>> initializeaza iar thread-ul are starea NEW. Am un task care trebuie
>> executat (functie). Nu trece in starea READY pana cand nu apelez
>> pthread_create cu respectivul task. Imediat dupa pthread_create, fac wait
>> pe semafor. Din acel task, eu imi schimb starea in READY si dau post pe
>> semafor, iar parintele adauga respectivul thread in coada ready
>>
>> 2. Am un mutex pentru intreg contextul scheduler-ului. Se apeleaza
>> so_exec. Fac lock pe un mutex. Structura se initializeaza cu thread-ul
>> avand state-ul direct READY; adaug thread-ul in coada ready si dau unlock
>> pe mutex, dupa care apelez reschedule() + return
>>
>> Care varianta este mai 'naturala' sau corecta?
>>
>
> Din punctul meu de vedere mi se pare mai 'naturală' prima variantă.
>
> Numai bine,
> Răzvan
>
--
Adrian Pop
Student @University Politehnica of Bucharest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/so/attachments/20180515/025f7d61/attachment.html>
More information about the so
mailing list