[pso] [tema2] Sincronizare

[Faur Andrei]

2009/4/11 Octavian Voicu <octavian.voicu at gmail.com>

> 2009/4/8 Razvan Deaconescu <razvan.deaconescu at cs.pub.ro>
>
>> On Wed, 2009-04-08 at 11:04 +0300, Cristian Sandescu wrote:
>> > Salutare,
>> >
>> >
>> >
>> > Imi pun problema daca este necesara sincronizarea accesului la
>> > bufferele kernel cu un spinlock ceva.
>> >
>> > Teoretic nu ar trebui sa existe instructiuni care sa modifice acelasi
>> > index din buffer, deci nu ar fi nevoie (avand in vedere ca intrarea in
>> > rutinele de r/w se face secvential).
>>
>>  In general depinde de implementare. Recomandam folosirea unui semafor
>> pentru accesul exclusiv la rutina de read si write (un singur proces are
>> acces). Buffer-ele kernel vor fi, astfel, accesate din rutinele
>> respective de un singur proces si din ISR. Primitivele de acces exclusiv
>> pot fi evitate prin folosirea de variabile atomice.
>>
>
>
> Eu nu inteleg cum variabilele atomice (cel putin cum sunt folosite in
> modulul case-lin) pot preveni race-urile.
> Sa luam un exemplul din case_write:
>
> static int case_write(struct file *file, const char *user_buffer, size_t
> size, loff_t *offset)
>         /* ... */
>         while ((atomic_read(&dev->fill) < BUFFER_SIZE) && size) {
>                 char c;
>                 /* ... */
>                 dev->buffer[dev->put]=c;
>                 dev->put=(dev->put+1)%BUFFER_SIZE;
>                 i++; size--; atomic_inc(&dev->fill);
>         }
>         /* ... */
> }
>

Din cate tin minte din codul case-lin, scrie la inceputul codului sursa, in
comentarii : NOT SMP safe.

Daca pui un semafor, doua procese nu vor accesa simultan bucata respectiva
de cod, deci ramane problema
de sincronizare intre un proces si ISR. Singura variabila shareuita de cele
doua este campul fill, care este modificat
atomic, deci nu sunt probleme. Campul put nu este accesat din intrerupere
(ci get), deci nu trebuie accesat atomic.
AFAIK doar variabla care iti arata dimensiunea bufferului e de interes comun
pentru intrerupere si ISR, deoarece
in rutinele read/write tu vrei sa iei/pui in buffer in timp ce in
intrerupere faci tocmai invers, si pentru asta accesezi
alte campuri.


> si urmatorul scenariu:
>
> 1. Doua procese au deschis device-ul.
> 2. La un moment dat, bufferul mai are un singur byte ramas gol.
> 3. Primul proces apeleaza write [1 byte].
> 4. Se executa syscall-ul si exact dupa intrarea in while (deci dupa
> atomic_read) procesul este preemptat.
> 5. Al doilea proces apeleaza write [1 byte] si intra si el in while
> (atomic_read returneaza aceeasi valoare ca mai sus).
> 6. In functie de cum sunt planificate procesele, rezultatele sunt
> imprevizibile (se poate pierde una din valori si chiar suprascrie prima
> valoare necitita din buffer).
>
> Poate imi scapa ceva, dar din ce vad eu in sursele kernelului atomic_read
> nu face nimic deosebit si nu are cum sa faca ce ar face un semafor.
>

True, nu e SMP safe. Tocmai de aceea trebuie un semafor. Si eu aveam
impresia la inceput ca bucata de cod din case-lin este SMP safe, dar nu e.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/pso/attachments/20090411/25a0181e/attachment.htm>