[elektro] idoosztasi strategia

[Karoly Kovacs]

Szep az onkritika. :)))

Na de most komolyan: en is (hozzad hasonloan) regi motoros vagyok, ezert 
eloszor _mindig_ es kizalolag magamban keresem a hibat.
Nota bene: egesz programozoi palyafutasom alatt (uszkve 36 ev) mindossze 
egyszer sikerult _bizonyithatoan_ aritmetikai hibat talalnom, amit 
_valoban_ a cpu kovetett el.

Karoly

On 30.07.2011 12:22, Nemeth Tibor wrote:
> 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
>
>
>
>
> -----------------------------------------
>            elektro[-flame|-etc]
>
>