[elektro] idoosztasi strategia

[Nemeth Tibor]

Hali!

Értem én, az a gond lövésem sincs a wondowshoz, ez amit művelek és 
nagyképűen experimentális programozásnak nevezek lényegében 
hályogkovácsolás.

2011.07.30. 1:26 keltezéssel, Info írta:
>> Ez a gombhoz rendelt eseménykezelő hozza létre a thread-et.
>> Gondolom a MY itt egy olyan memória területet jelent ami a thread
>> példány működéséhez szükséges adatokat tartalmazza. De hogyan lehet ez
>> lokális változója egy eseménykezelőnek, hiszen a thread sok másodperccel
>> az után is fut, hogy az eseménykezelő már kilépett és nyilván
>> felszabadította a stacket.
>
> Jujj. No, nézzük sorban:

Mentségemre legyen, ez egy internetről letöltött példa volt, 
kipróbáltam, működött, tetszett, de az említett dolog szembeötlött.

>
>> procedure TForm1.Button1Click(Sender: TObject);
>> var
>>      MY : TTesztThread ;
>
> Jól tudod, a veremben csinál egy mutatónak helyet.
>
>> begin
>>     MY := TTesztThread.Create(True) ;
>
> A TObject.Create függvényig lefut minden öröklött Create fgv, és a
> foglalás itt történik, a címét visszaadja az objektumnak.
>
> Beteszi az objektum címét a veremben foglalt mutatóba, hogy hívni
> tudja a metódusokat a VMT-ből.

Bocs, feledékeny nagyok, pár éve olvastam, a VMT mindig globális, ezt 
feletettem el. Így már értem, a MY  a stacken, csak a mutató
>
>>     MY.Honnan := 'D:\teszt.vmi' ;
>>     MY.Hova := 'C:\teszt.vmi' ;
>>     MY.Resume ;
>
> A tárolt mutató felhasználásával az objektum részeit eléred, írsz
> bele, futtatod a Resume fgv-t.
>
>> end ;
>
> Naszóval, innentől sehol nem fogod tudni elérni ezt az objektumot.
> Tulajdonképpen eldobtad a címét, magárahagytad.
> Saját magának kell felszabadulni, kilépni a memóriából majd valamikor,
> stb.
>
> Amikor újrahívod ezt a ButtonClicket akkor egy újabb objektum jön
> létre és fut.

Esetemben ezt majd el is kell kerülni, hiszen egyedi hardvert kezel
a szál és ha több példány tenné ezt tragédiába torkollna.

> A baj ezzel a megoldással az, hogy amikor bezárod a processt akkor
> leállnak a threadok ha a process leállításakor nem akarod megváratni.
> Azaz mondjuk félbeszakad a végrehajtás. A processz a szálak csoportja.
>
> Javaslom soha ne dobd el így az objektum címét és kilépéskor akár
> OnClose-ban akár finalizationban érd el a száladat és szólj neki, hogy
> söprés kifele a memből mert a rendszer/user kirúgja hamarosan.
> Az elegáns megoldás az, ha az OnCloseQuery-be teszed és addig nem
> térsz vissza amíg le nem álltak a szálak. Mondjuk felugró ablak "kérem
> várjon" vagy valami.

Köszönöm és megfogadom.

> Még két dolog a szálakhoz delfiből: az egyik, hogy csak az execute()
> maga a szál, az összes többi objektum-elem nem tartozik hozzá.
> Induláskor ha createsuspended false akkor azonnal elindul és ha
> lokális változókat nem inicializálta a rendszer hibásan fogsz futni. A
> fenti példában ezért volt true a suspended, majd beállítótta a loc
> paramokat majd resume/folytatás. Így létrehozás után nem olvassa a
> hülyeséget egyből hanem vár.
Ok. Ezt értem.
> A Suspend/resume nem tudja hol áll a szál. Éppen egy másik belőle
> hívott fgv közepén is megállhatsz ha suspendet hívsz.

Ezt még nem próbáltam és nem is értem illetve gondolok róla valamit de 
nem tudom helyes-e.
Ugyan mint fent írtam, nem ismerem sanjos a windows működését, de azért 
azt tudom, hogy a szálak között valahogyan kiosztja a CPU-t. Sejtésem 
szerint, a Create, azon kívül, hogy létrehozza a megfelelő memória 
tartalmakat, valahova bejegyzi ezt az új szálat, hogy beálljon a sorba. 
Gondolom a Suspend/Resume  ezt a bejegyzést törli/írja vagy ha van ilyen 
jelzője, teszi inaktívvá/aktívvá. Így van?

> A terminate fgv pedig nem csinál az égvilágon semmit, csak a Treminate
> változónak ad true értéket.
Ezek szerint a szálnak akkor van vége, ha az execute eljut a végén az 
end-hez,amit persze okozhat a terminate=true,de egyéb okból is eljuthat 
oda. Tehát ha már eljutottunk az execute-t lezáró end-ig, van-e még 
jelentősége a terminate változónak ?
A FreOnTerminate jelentését azt hiszem értem, de ebben például lehet 
jelentősége a terminate változónak. Mondjuk pillanatnyilag nem tervezem
ennek használatát, de jó lenne tudni hogy is van.

Ha már egyszer eljutott az execute az endhez és nem volt free, akkor mi 
a helyzet? Lehet-e újraindítani? Mit csinál a Resume?

>
> A másik a vizualizálás: sok időt elvesz és ami bonyivá teszi: a win
> alap objektumaira van ráhúzva.  Tehát pl. a TCombobox egy sima Edit
> mező, natúr üzenget az objektumod neki, hogy most így jelenjen meg
> most úgy, stb. No szóval oda akarok kilukadni, hogy a többszálúság
> ugyanazt a fgv-t hívhatja/üzenetet küldheti többször, ezért kitalálták
> a Synchronize() metódust amit a szálból kifelé híváskor kell
> használnod. Tehát az executen-belül, és mégpontosabban akkor ha
> vizuális dolgot hívsz, VCL komponenst. Ez a synchronize azt csinálja a
> háttérben, hogy létrehoz egy eventet, beteszi a száladat a
> waitforsingleobject()-re, talán még lockolja is aztán meghívja a
> kívánt függvényt, majdha visszatért a hívott fgv setevent és
> folytatódik a szál futása.

Azt, hogy miképpen kell használni és miért szükséges azt értem, a 
részleteket sajnos nem igazán de ez az én hibám, Te megtetted amit lehet.

> Az Application objektum meg ott bugzik egy kicsit a szálakkal, hogyha
> a szálban vársz egy értékre amit ugye VCL-ből kapsz mondjuk checkboxra
> vársz, aztán az alkalmazás is vár a szálra na akkor várhatnak az idők
> végezetéig :) ugyanis a win alap getmessage/processmessage-ja az
> applicationba fut és ő osztja szét a formoknak. Namost ez egy szál,
> meg Te csinálsz másikat és a kimenete is meg a bemenete is ugyanúgy
> állni fog. Nemtom érted-e. Példával:

Ok, ezt értem, dead-lockot már 76-ban is tanították.


> Ha a száladra akarsz várni elegánsan akkor időnként kell
> app.processmsg valahogy így:
>
>   while WaitforSingleObject(hEvent, 20)<>  wm_Timeout do
>      Application.ProcessMessages.
>
> Így az alkalmazás alap szála időnként lekezel 1-1db win üzenetet,
> talán nem veszlik el az egérklikkelés a sorból és meg tudod várni az
> indított szálból küldött eventet.
>
> Mondjuk ide meg már érdemesebb pipet vagy wm_userxxx üziket
> küldözgetni.

Hát ezt még nem fogom fel pillanatnyilag, de már látom hol kell túrni a 
helpet. Persze ismerősek ezek, ami sajnos annyit tesz, hogy már régebben 
is nekifutottam és elakadtam, de a remény hal meg utoljára.

Ezer köszönet

                           Németh Tibor