Threads and .....s :)

Zdrawejte,
Problema e slednia: Ima edin redaktor na kojto triabwa da mu se napishe class view. Class view-to go napisah i batchka kato pich, obache ima slednia problem:
Neka e otworen project w redaktora (za da e po-kriwo predpolagame che ima mnooogo file-owe). Neka susto taka niakoj widioten potrebitel ne me gali, a e naotworil goliamo kolichestwo file-owe ot project-a i e pipnal po nesto tuk i tam.
Programata koiato "proizwegda" tag-owe e wunshno exe (dori i da e dll ili static lib towa ne e wagno) i pri promiana na sudurgianieto na file-a (redakzia) go preparswa - zaedno s drugi promeneni file-owe koito sa chast ot project-a. Puskaneto na exe-to, zaregdaneto i wizualizatziata na tag-owete sa w otdelen thread.
Problema e kato trugne chowek da spira prilogenieto - togawa wariantite sa 2:
1) da chakam thread-a (ako w momenta wurwi) da swurshi i da si se zatwariam.
2) da terminiram thread-a i da se oleia w memory leaks :).
2.1) da opitwam da lugia :) i wse pak da polzwam TerminateThread - w thread-a da ne zadeliam pamet, a da polzwam razni globalni container-i za tagowete, taka che kato spra thread-a i toj gi e napulnil doniakude te wse pak da se triat (iasno e che containerite sa pulni s ukazateli kum object-i deto triabwa da se triat :) ).
Towa spored men e kasapsko reshenie na hirurgicheski problem :)
3) Event-i za da suobstia na thread-a da si chisti "smetkite" obache susto ne e mnogo dobro reshenie spored men.
Hmmm maj mi swurshiha ideite :)

Според мен т.3 - с event-и е най-чистото решение. Пак ще чакаш thread-a да свърши, но би трябвало това да стане по-бързо, т.е. веднага като set-неш terminate event-а.
Щом става дума за парсване на файл, би трябвало да има цикъл, т.е. на всяка итерация, можеш да правиш:

bTerminated = ( WaitForSingleObject( hTerminateEvent, 0 ) == WAIT_OBJECT_0 );
if ( bTerminated ) break;

и после си знаеш...

---
Не е важно да си добър, важното е да си ман-и-як!

Ами да, определено точка 3. Още повече че доколкото разбирам, thread-ът не извършва блокиращи операции.

Само че от тоя Event няма нужда точно вътре в цикъла, защото все пак си е overhead. Там е достатъчно и да проверяваш някакъв volatile булев флаг. Event variable може да свърши работа извън цикъла, например ако нишката спи и чака да и се отвори работа.

Aham - niama nugda ot tolkowa mnogo proverki za event-a. Ne e fatalno ako rabotata na samiat thread se razbie na niakolko "block-cheta" i za event se proweriawa megdu tiah - ili ako se wika wunshno exe da na CreateProcess da se chaka s WaitForMultipleObjects. Ako dojde purwo event-a za app. close ostanalite chasti (t.e. tam kudeto se zadelia pamet) izobsto ne se izpulniawat.
Mersi na wsichki!

Просто питане. Все пак при затваряне на win32 процес не се ли освобождава заеманата от него памет, независимо дали нишките му са работили или не в момента на затварянето?

Просто за протокола :

Извадка от Platform SDK docs:

DWORD WaitForSingleObject(
HANDLE hHandle,
DWORD dwMilliseconds
);
....

dwMilliseconds
[in] Time-out interval, in milliseconds. The function returns if the interval elapses, even if the object's state is nonsignaled. If dwMilliseconds is zero, the function tests the object's state and returns immediately. If dwMilliseconds is INFINITE, the function's time-out interval never elapses.

Не че няма да има overhead, но ако не е найстина време-критично, по-добре е да се ползва тази функция, защото операционната система ще се грижи за всичко.

---
Не е важно да си добър, важното е да си ман-и-як!

тц

аз ползвам два volatile флага - единия спира нишката, другия се вдига при излизане. брех мааму, докато зацепя че трябва да се volatile! бре в дебъг бачка в релийз не ще!

Moje li i az prosto wypros
Zashto ne si zatworish prozorcite i pak da si chakash da swyrshi thread-a? i da si pochistish...
Kolkoto i da se zabawq towa - ne e widimo za USER-a taka che toi si misli che wsichko e prikljuchilo
problem mojesh da imash samo pri shutdown ama to togawa USER-a taka ili inache nqma kakwo drugo da prawi oswen da chaka

-------------------------------
Koito go moje - go moje!

Айде по протокола :)
Вярно че е immediately, но си остава function call. Сравни скоростта на:

1. Да се push-нат двата параметъра в стека, да се call-не, да се направи проверката дали dwMilliseconds е 0, да се ret-не, и да се направи проверка дали резултата е WAIT_OBJECT_0;

2. Да се тества един volatile bool флаг.

Значи, признавам си без бой, че забележимо забавяне в скоростта е 99% изключено да има. Ще има само ако това едва ли не единствената инструкция в цикъла.

От друга страна, не съм съгласен дето казваш, че "по-добре е да се ползва тази функция, защото операционната система ще се грижи за всичко". Защо да е по-добре? Какво ни дава повече тази функция? По-лесно ли е? По-бързо ли е? По-малък ли ще е кода? По-красиво ли е, или пък по-елегантно? Защо, когато решението е просто и лесно, трябва да се насилваме да ползваме майкрософтската функция?

Винаги е добре да се избегне context-switch, ако може. Event-ите са kernel-обекти, така че всичко което ги ползва, неминуемо влиза в kernel mode, включително и WFSO.

Ami to az za volatile flag-a i predi da postna si misleh - ste stane i to burzo. Edinstwenia wupros beshe che me murzeshe da pisha prowerki na flag-a w code-a na thread-cheto :).
A kolkoto do zatwarianeto na dgiamowete i posle da chakam thread-a da swurshi - niama da se poluchi osobeno kato se ima predwid che thread-a ima rabota s opredeleni dgiamowe :)

ako imash predwid che risuwash ot thread-a nema po-lesen nachin - w momenta w koito IsWindow wyrne FALSE spirash thread-a i se iznasqsh daje i flag ne ti tqbwa inache ne wijdam drug PB...

-------------------------------
Koito go moje - go moje!

Mi po-dobre e shtoto ne spin-lockwash kato otkachen. Pri WaitFor... threada zaspiwa, pri twoia wariant spinwa, aide za 2 threada ne e koi znae kakwo, tam switchwane na contexti i prochie kucheta gi iali...ma ako imash malko poweche threads shte se chudish prosto kakwo stawa :)

Ама тук въобще не става дума за spin lock :)

aha, a vyrtene v cikyl na { if (flag) } kak go narichash? ;)

Oswen az da sym poludial de, koeto hich ne bi me uchudilo :)

Spin lock го наричам.

Но тук не става дума за въртене на цикъл. Става дума за нещо много по-просто. Например:

if (exitFlag) return;

Така добре ли е? :)

dobre e :)

siguren li si? ne zwuchi dobro reshenie ot strana na Microsoft? kakvo stava sus wsichkite tezi prilozhenija koito spiram nasila - ne im spirat threadovete li? ne zwuchi logichno

Samo za protokola Threadfunction e defined
UINT func (LPVOID lpvData)

koeto znachi che trqbwa da e
if (bExitFlag) return uRetVal;



May the beer be with you

-------------------------------
Koito go moje - go moje!