[so] [Tema4][Linux] Nelamurire logica test Ring
Maydan3zzu Screwie
maydan3zzu_screwie at yahoo.com
Sat May 23 02:40:19 EEST 2009
Imi cer scuze pentru numele asociat adresei de e-mail. Pe viitor voi reveni cu o adresa mai "decenta"
Traian
----- Original Message ----
From: Maydan3zzu Screwie <maydan3zzu_screwie at yahoo.com>
To: so at cursuri.cs.pub.ro
Sent: Saturday, May 23, 2009 2:31:42 AM
Subject: [Tema4][Linux] Nelamurire logica test Ring
Salut,
Am o problema in a intelege logica din spatele testului ring.
Cum vad eu desfasurarea testului:
- se porneste threadul master
- se pornesc NUM_THREADS threaduri care asteapta la conditia NUM_THREADS
- threadul master trimite un broadcast al conditiei NUM_THREADS care muta threadurile din coada conditiei
NUM_THREADS in coada de waiting
- threadul master elibereaza monitorul, permitand celorlalte threaduri sa acapareze pe rand monitorul si sa astepte
fiecare la cate o conditie
- threadul master semnalizeaza conditia 0, threadul 0 trece in waiting, apoi in running si semnalizeaza conditia 1
Din acest moment, aparent eu consider altfel decat testele:
Eu consider ca:
- deoarece politica este SIGNAL_AND_CONTINUE, threadul 0 continua executia, apoi cedeaza accesul la monitor
si ajunge la acel testAndFail, in care se asteapta ca un thread sa fie waiting, thread inexistent, deoarece semnalul
nu "a ajuns" la threadul 1. In concluzie, pica testul
Dupa destul de mult "debug cu printf-uri" am inteles ca testul doreste urmatorul scenariu:
- threadul 0 continua executia, cedeaza monitorul, permitand threadului 1 sa observe semnalul primit pe conditia sa,
si sa treaca in waiting, abia apoi urmand sa se realizeze testAndFail-ul
Mentionez ca prin introducerea unui sleep() intre semnalizarea efectiva a conditiei si intoarcere din functia Signal
ceruta in implementarea temei, testul trece, dar nu cred ca aceasta este varianta dorita. De asemenea, consider ca implementarea mea este "race-proof"
Orice idei sunt bine-venite.
Multumesc,
Traian Popeea
More information about the so
mailing list