[pso] Fwd: Re: Probleme Tema 3 Linux

Victor Asavei pso@cursuri.cs.pub.ro
Sat, 1 May 2004 11:22:36 -0700 (PDT)


On Saturday 01 May 2004 18:52, you wrote:
> Buna ziua
> Imi cer scuze pt deranj si mentionez ca nu trimit
> acest mesaj pe lista deoarece vreau sa intreb niste
> lucruri legate de implementarea mea pt tema 3.
> Prima problema o am la mecanismul de sincronizare
> kernel thread - functie de request:
> In principiu am gandit urmatorul mecanism de
> sincronizare kernel thread - functie request:
> - la initializarea kernel threadului (pt
sincronizarea
> cu functia de request) acesta va face down pe un
> semafor (ce este initializat la incarcarea modulului
> cu valoarea 0) si va astepta pana cand in functia
> request se va citit o cerere si in functia de
request
> executand up kernel threadul va putea prelucra
cererea
> - in functia de request se va extrage cererea din
> coada, se va face up pe semaforul kernel threadului
pt
> a-i da drumul si pt sincronizare va incerca sa
obtina
> un spinlock (spin_lock(&spin) )...care ar trebui sa
> aiba valoarea de ocupat si sa fie liber numai dupa
ce
> kernel threadul termina de prelucrat cererea si va
> face spin_unlock (&spin)
>

Abordarea e gresita: functia din functia de request
trebuie sa iesi cat 
mai 
repede. In nici un caz nu poti astepta dupa kernel
thread, are face 
operatii 
blocante.

> Problema apare aici...de fiecare data cand fac
> spin_lock(&spin) se comporta ca si cum ar ignora
acest
> apel...sau ca intotdeauna &spin este liber...pana si
> doua apeluri succesive:
>
> spin_lock(&spin);
> spin_lock(&spin);
>

Pentru ca linux v2.4 nu este preemptiv, pe masini
uni-procesor 
spin_lock() nu 
face nimic.

> Mentionez ca daca folosesc in loc de spinlock un al
> doilea semafor pentru sincronizarea functie request
-
> kernel thread programul functioneaza bine si trece
> toate testele...insa nu cred ca e corect ca in
functia
> de request sa astept la un semafor deoarece aceasta
> trebuie sa fie atomica si nu este rulata in
contextul
> vreunui proces in particular.
>

Dupa cum ai precizat si tu, nu ai voie sa folosesti
apeluri blocantein 
functia 
de request, pentru ca se executa dintr-o functie
defferable, deci 
dintr-un 
context arbitrar.


>
> O alta problema care a aparut este faptul ca testul
> imi da passed si atunci cand nu ar trebui ! Am
> comentat in program partea unde fac efectiv read si
> write din fisierul conectat in/din CURRENT->buffer
si
> totusi testul vede ca si cum datele sunt
scrise/citite
> corect.
> Am rugat cativa colegi care terminasera si ei tema
sa
> comenteze de curiozitate si ei partea in care faceau
> scrierea/citirea si efectul era acelasi.
> Nu imi dau seama erxact ce se intampla...cred ca de
> fapt verificarea in test tine mai mult de
> end_requestul pe care il dau din kernel thread dupa
> copierea/scrierea datelor decat de datele
> insasi...sau...poate cauza este alta :(

Da, din user space nu poti sa vezi decat ce spune
end_request().
Daca insa nu faceti read/write-ul oricum o sa dea
eroare la "data 
check".

tavi

PS: consider ca mesajul nu contine nimic special si ca
poate fi trimis 
pe 
lista; dac nu te deranjeaza, fa un fwd pe lista la
mailul asta (poate 
mai 
lamureste pe cineva)


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover