Pogledao sam clanak.
Resenje 3.1 je pogresno (kao sto i pise), ali je i 3.2 pogresno (iako to ne pise, ili ja nisam zapazio), lepo moze unlock() da otkljuca thread pre nego sto se on zaista zakljuca, bas kao u 3.1.
3.2 ima samo proveru da li je thread otkljucan, uopste ne moze da vidi da li je thread zaista zakljucan, nema mehanizam da spreci race-condition.
Resenje 3.3 je OK, mada su ga ukomplikovali preterano.
Takvo resenje je meni palo na pamet, pre nego sto sam ga video u ovom clanku, samo mnogo mnogo jednostavnije, bez duplog mutex-a.
To resenje nije nista 'novo' sto nisam znao, funkcija za otkljucavanje se ne zavrsava sve dok se thread zaista ne oTkljuca, i to moze da se realizuje uz pomoc samo jedne promeljive, ovako:
Code:
int pthread_cond_signal (...)
{
[..] // proverava da li je thread zakljucan
unlocked=0;
while (unlocked==0)
ResumeThread (pid);
}
int pthread_cond_wait (...)
{
[..] // proglasava thread zakljucanim
cs.leave();
SuspendThread (pid);
unlocked=1;
cs.enter();
[..] // proglasava thread otkljucanim
}
To je u osnovi to resenje, samo sto su oni ubacili dodatni mutex, pa imaju neki counter... i naravno koriste Event-e, sto ja ne koristim.
U principu, mozda je njihov sors OK ako nekome treba counter i ako neko koristi Event-e, ali meni counter ne treba, i ne koristim Event-e.
E sada, resenje 3.4 je zanimljivo.
U mom Win32API Reference help-u, koji sam uzeo od Delphi-ja 5, pise da SignalObjectAndWait() moze da se koristi za Mutex-e (izmedju ostalog), a o CriticalSections nema ni govora.
U resenju 3.4, funkciju SignalObjectAndWait() koriste bas u kombinaciji sa CS-om !!!
U cemu je fazon?
Nisam probao da li resenje 3.4 zaista radi, pa me interesuje da li su ovi, koji su pisali clanak, proverili to resenje na delu?
Ili je u pitanju prica da MS slucajno ili namerno nije ubacio CS u listi tipova koje ova funkcija prima?
Jos jedna nedokumentovana stvar?