[pso] [tema2] Sincronizare

[Octavian Voicu]

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);
        }
        /* ... */
}

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.


@ Vlad
> Este ok daca in loc de sincronizare am facut ca dispozitivul sa nu suporte
> mai multe deschideri simultane? (-EBUSY la open() la urmatoarele)

Daca deschizi device-ul si apoi dai fork() amandoua procesele au acces la
fisier/device si atunci apar probleme cu accesarea simultana, parerea mea.
Acelasi lucru s-ar intampla si intr-o aplicatie multi-threaded.



-- 
Octavian Voicu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/pipermail/pso/attachments/20090411/ab29e9aa/attachment.htm>