[so] [tema2] Windows vmchecker

Adrian Scoica adrian.scoica at gmail.com
Wed Apr 13 13:57:26 EEST 2011


2011/4/13 Drutu Bogdan <bogdandrutu at gmail.com>:
> 2011/4/12 Adrian Scoica <adrian.scoica at gmail.com>:
>> 2011/4/11 Stefan Munteanu <stef8803 at gmail.com>
>>>
>>>
>>> Apreciez boldul pe "cearii", chiar sare in ochi cuvantul :D
>>> Totusi, cred ca exista solutii mai elegante pentru sincronizare: de
>>> exexmplu, un semafor.
>>> Alternativ, ai putea sa renunti la sincronizare, creeand atat in
>>> client si in server semaforul (O_CREAT creeaza doar daca nu exista).
>>
>> Daca am inteles bine, este vorba despre implementarea pe Windows.
>>
>> Solutia cu semafoarele va functiona in continuare, dar va trebui sa ai
>> grija sa pastrezi semafoarele deschise in ambele procese pana cand nu
>> mai ai nevoie de ele, deoarece in Windows ele se sterg daca nu mai
>> exista nici un handler deschis la ele in vreun proces viu. Astfel, te
>> poti trezi in urmatoarea situatie:
>>
>> Proces1:
>>    * deschide semafor
>>    * da release pe el (sem_count == 1)
>>    * inchide semafor (se distruge semaforul)
>>
>> Proces2:
>>   * deschide semafor (il recreaza, pentru ca s-a sters intre timp)
>>   * face wait pe el si asteapta la infinit (pentru ca s-a pierdut
>> release-ul celalalt)
>>
>> Exista insa in continuare problema sincronizarii dintre client si
>> gateway. Gateway-ul trebuie sa creeze mailslot-ul inainte ca client-ul
>> sa il deschida pentru scriere. Deoarece clientul este gata implementat
>> si nu are un mecanism de sincronizare la operatia de deschidere a
>> cozii de mesaje... e cam random. Ma rog, mie mi-a mers aproape mereu
>> in ordinea corecta, dar din punctul meu de vedere implementarea este
>> gresita.
>
> Ok, daca se face cu semafoare sincronizarea intalnesti problema expusa
> de tine, atunci cum crezi ca ar trebuii sa se realizeze aceasta
> sincronizare?

Este OK cu semafoare, dar trebuie avut grija in Windows.

A) gateway - server

   O solutie aici este ca ambele procese sa pastreze semafoarele
deschise pana la finalul executiei. Asta mi se pare mai degraba quick
& dirty. Alta solutie ca sa te asiguri ca nu se distrug intre timp
este sa sincronizezi prin doua semafoare "in X" (improvizezi o
bariera), astfel:

Proces 1:

    deschide sem_1  si sem_2

    da release pe sem_1
    da acquire pe sem_2

    le inchide pe amandoua

Proces 2:

   deschide sem_1 si sem_2

   da release pe sem_2
   da acquire pe sem_1

   le inchide pe amandoua

Chestia asta este "safe" pentru ca nici unul dintre procese nu are cum
sa inchida un semafor pana cand celalat proces nu l-a deschis deja (ca
sa il inchida, trebuie sa treaca prin acquire => trebuie ca procesul
celalalt sa treaca prin release => trece si prin open) => nu se pierd
semnale.

B) client - gateway

Clientul ar putea sa se blocheze si el intr-un semafor pana cand
primeste de la gateway un semnal ca e OK sa treaca mai departe pentru
ca s-a creat deja mail slot-ul.

Inteleg insa de ce nu ai implementat asa, pentru ca gateway-ul ar fi
trebuit sa cunoasca dinainte numarul de clienti care se conecteaza la
el ca sa stie sa dea suficiente release-uri.

Totusi, se poate face altceva. Gateway-ul sa dea primul release, si
clientii sa dea acquire si apoi release pentru urmatorul client.
Ultimul client da un release in plus, dar asta nu cred ca e o
problema, pentru ca iti permite sa adaugi clienti noi oricand.

In cazul asta, insa, gateway-ul ar trebui sa pastreze acel semafor
deschis pe toata durata executiei sale (in Windows, cel putin).

Oricum, nu cred ca exista o solutie perfecta. Toate astea or sa o ia
pe aratura daca moare subit un proces.


More information about the so mailing list