MFC - Problem sa CCriticalSection - assert kada stavim lock(!= 0)

[ ljube @ 04.10.2005. 14:11 ] @

Pokusavam da napravim sinhronizaciju thredova sa CCriticalSection.

CCriticalSection* mi_cs;

Kada koristim mi_cs.Lock() metod bez parametara, onda izgleda da sve radi normalno, ali kada pokusam da stavim mi_cs->Lock(2000) onda mi program javalja:

Debug assertion failed! - afxmt.inl na liniji 81

Pokusao sam da korisitm u kombinaciji sa CSingleLock singleLock(mi_cs);
singleLock.Lock(2000);
...
singleLock.Unlock();

Ali opet isti slucaj.

Pretpostavljam da nesto nisam uradio kako treba.
Dali neko zna gdje sam pogrjesio?

[ milanche @ 08.10.2005. 06:54 ] @

Obicno se to radi ovako:

#include <afxmt.h>

pa negde deklarises kriticnu sekciju - najbolje je u header fajlu cele klase (tj. napravis
da bude member variable), posto po prilici trebas da stitis pristup resursima kojima pristupaju razlicite metode iste klase.

CCriticalSection m_cs;

onda imas dve opcije. Jedna je da kritican deo koda ogradjues sa:

m_cs.Lock();
...kod koji stitis...
m_cs.Unlock();

A druga opcija je sa CSingleLock() -om:

CSingleLock lock(&m_cs);

Ova druga metoda je elegantna ali ogranicavajuca jer nemas finiju kontrolu gde tacno
hoces da unlock-ujes kriticnu sekciju, nego moras da cekas da cela funkcija ode out of
scope, sto nekad nije zgodno - nema smisla ogranicavati thread-ove predugo.

Osim toga, primetio sam u par scenarija da se CSingleLock ponasa vrlo cudno, te da
zapravo ne odradi to sto bi se ocekivalo.

Moja preporuka je da se uvek oslanjas na prvu metodu koju sam opisao.

[ milanche @ 08.10.2005. 07:09 ] @

E, da - gde si pogresio ?

Ne mozes da koristis puki pointer na tip CCriticalSection - on mora da pokazuje na
postojeci objekat tipa CCriticalSection, koga nigde nisam video da si kreirao bilo
staticki (kao u primeru koji sam naveo) niti dinamicki (kao naprimer:

Code:
CCriticalSection* p_cs = new CCriticalSection();

Ako si tako uradio kako si napisao, pravo je cudo da je ista radilo.

[ X Files @ 08.10.2005. 07:34 ] @

Mozes da koristis i cist API za CriticalSections u kombinaciji sa RAII pristupom:

// PSEUDO

--- H ---

Code:

class ... neka klasa ...
{
   // ...
   CRITICAL_SECTION MyCriticalSection;
   // ...
};

class CSLock
{
public:
   LPCRITICAL_SECTION fcs;

   CSLock( LPCRITICAL_SECTION acs ) : fcs( acs )
   { if ( fcs ) EnterCriticalSection( fcs ); }

   ~CSLock()
   { if ( fcs ) LeaveCriticalSection( fcs ); }
};

--- CPP ---

Code:

KONSTRUKTOR
{
   InitializeCriticalSection( &MyCriticalSection );
}

DESTRUKTOR
{
   DeleteCriticalSection( &MyCriticalSection );
}

METODA
{
   CSLock Lock( &MyCriticalSection );
   KOD KOJI STITIS();
   // ma sta se desilo u KOD KOJI STITIS()
   // ... bice otkljucano, sto je posao destruktora Lock objekta...
}

Na ovaj nacin obezbedjused da se funkija otkljuca bez obzira sta se desilo
u funkciji KOD KOJI STITIS(), koji moze i da 'pukne'.

[ ljube @ 08.10.2005. 08:25 ] @

Hvala na odgovorima,

Zbog jednostavnosti prikaza problema nisam navodio:

Code:

CCriticalSection* p_cs = new CCriticalSection();

ovo sam naravno napravio u konstruktoru klase a u destruktoru brisem CCriticalSection, ali je problem kada stavim neku vrijenost u lock koja je razlicita od nule (to bi trebao da bude wait timeout).

Pokusao sam i ovako da deklarisem varijablu:

Code:

...
CCriticalSection m_cs;
m_cs.Lock(1000);
...

ali isti problem se ponavalja kada stavim neku vrijednost za lock timeout. Kasnije sam pokusao i preko pointera na CCriticalSection, pa sam onda pokusao i sa CSingleLock.

Sve ove klase navodno imaju mogucnost da se stavi wait tiemout.

Prije sam koristio CRITICAL_SECTION ali on nema mogucnost za wait timeout pa je to razlog zasto pokusavam sa nekom gotovom klasom (MFC).

_{[Ovu poruku je menjao ljube dana 08.10.2005. u 09:26 GMT+1]}

[ ljube @ 08.10.2005. 08:54 ] @

Evo uploadovao sam primjer koda i gotove programe koji demonstriraju problem (530Kb):

[url]
http://www.programbl.com/MFC/CCriticalSectionCrash.zip
[/url]

Problem sa assertom se naravno desava samo u debug build.

Potpuno sam zbunjen zasto ne radi.

Ja sam pravio upgrade VS2003 preko VS2002, mozda imam losu instalaciju.

_{[Ovu poruku je menjao ljube dana 08.10.2005. u 09:55 GMT+1]}

[ yooyo @ 08.10.2005. 11:38 ] @

Citat:

CCriticalSection::Lock
See Also CCriticalSection Overview | Class Members | Hierarchy Chart | CSingleLock::Lock

Call this member function to gain access to the critical section object.

BOOL Lock( );
BOOL Lock(
DWORD dwTimeout
);

Parameters
dwTimeout - Lock ignores this parameter value.

Return Value
Nonzero if the function was successful; otherwise 0.

Critical section nezna za pojam timeout-a. To je jednostavan mehanizam koji osigurava da se neki deo programa izvrsava samo u jednom threadu. Svi ostali threadovi koji se nadju na ulasku u taj deo programa bice suspendovani dok thread koji se nalazi u kriticnom delu programa ne zavrsi svoj posao. Timeout nema smisla, jer na taj nacin kriticna sekcija postaje besmislena.

Mogao bi da nam objasnis sta zelis da izvedes. Postoje i drugi mehanizmi sinhronizacije koji su mozda bolji za upotrebu (Event, Mutex, Semaphore).

yooyo

[ ljube @ 08.10.2005. 16:53 ] @

Problem sam uspio rjesiti upotrebom WaitForSingleObject i signalizacijom odgovarajuceg eventa.

Evo opisa sta sam htio postici:

Rijec je o MFC/ATL ActiveX objektu koji koristi vise thredova.
Sinhronizacija izmedju thredova je rijesena preko CRITICAL_SECTION objekata.
Do ovog dijela nista nije sporno.

Dio koji mi je sporan, je event mehanizam.
Kontrola sada koristi PostMessage da bi ubacila signal u message loop kontrole kada je vrijeme da se signalizira neki event.

Kao sto znamo PostMessage ne ceka na potvrdu vec odmah nastavlja izvrsenje programa (sto logika mog programa trenutno zahtijeva).

Problem koji se javio je kada testni program ne moze da obradi sve evente na vrijeme, a kontrola ima mnogo eventa za slanje (ovo nije realan scenarij, vec samo stress-test kontrole).

Primjer problema je kada sam u VB6 aplikaciji, u obradi eventa, izbacio MsgBox. Ostali event se nisu mogli obraditi i doslo je do pucanja test programa.

Test prorgam ne puca ako stavim neku vrstu sinhronizacjie poput CRITICAL_SECTION ali onda je cijeli event mahnizam zamrznut dok klijent ne vrati kontrolu.

Ovo mi se nije dopalo pa sam htio iskorisiti neki timeout mehanizam, odnosno da kotrola ipak nastavi sa radom nakon (5 sekundi) - pa sta bude bude :)

Mislio sam da CCriticalSection lock metoda moze koristiti wait timeout.
Pogrjesio sam sto nisam potrazio detaljnije objasnjenje Lock metode.

U svakom slucaju hvala svima na odgovorima.

Samo ne razumijem zasto su napravili overload metodu:
dwTimeout - Lock ignores this parameter value.
koja se ne moze koristiti?

_{[Ovu poruku je menjao ljube dana 08.10.2005. u 17:56 GMT+1]}

[ yooyo @ 08.10.2005. 19:14 ] @

CCriticalSection je izveden iz CSyncObject koji u sebi ima metodu Lock sa timeoutom. Ovaj timeout se ne moze primeniti na critical section pa su ubacili assert da te upozore na potencijalnu gresku u upotrebi CCriticalSection.

yooyo

[ ljube @ 08.10.2005. 20:33 ] @

Hvala yooyo!