[pso] [T1]Spinlock-uri vs Semafoare

Silviu-Ionut Ganceanu silviug at gmail.com
Fri Mar 14 16:29:15 EET 2008


OK,

Atunci care este solutia care evita race-ul ce apare:

spin_lock()
... // verificari, alte chestiuni pregatitoare
spin_unlock()

// ----> race, aici poate interveni un release

ret=apel_de_sistem_vechi(...)

spin_lock()
... // alte prelucrari dupa apel
spin_unlock()

O solutie este pastrarea apel-ului de sistem vechi si dupa release. Totusi,
solutia nu este "curata" ba chiar are mireasma de hack :) Asta pentru ca
release-ul nu ar trebui sa se intample cat timp interceptorul este in
executie -- cel putin asa cred eu.

Silviu

2008/3/14 Octavian Purdila <tavi at cs.pub.ro>:

> On Friday 14 March 2008, Diana Elena Kelerman wrote:
> > Salut,
> >
> > De ce este indicat sa folosim spinlock-uri si nu semafoare?
>
> Daca inteleg eu corect vrei sa folosesti ceva de genul:
>
> sem_down(); -> semaforul e per apel de sistem
> ...
> ret=apel_de_sistem(...)
> ...
> sem_up();
>
> return ret;
>
> Pentru implementarea de mai sus, avem urmatoare problema:
>
> se executa procesul 1: sem_down(); read(socket, buffer, count); -> se
> blocheaza aici si nu vin date pe socket
>
> mai tarziu, se executa procesul 2: sem_down(); -> se blocheaza aici pana
> cand
> vin date pe socket-ul procesului unu
>
> tavi
> _______________________________________________
> pso mailing list
> pso at cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cursuri.cs.pub.ro/pipermail/pso/attachments/20080314/c9ca0c67/attachment-0001.htm 


More information about the pso mailing list