assembly kod

[HWSW Famulus]

> From: "Gyapai Jozsef" <gyapo at axelero.hu>
> > Most mar nyugodtan lehetne irni valami 5 perces ciklust a legmagasabb
> > prioritasban, KJ meg megmondja mit kell figyelni hogy kideruljon
kapott-e
> > kozben idot az oprendszer. NT4-en szivesen lefuttatom es beszamolok az
> > eredmenyrol.
> >
> >
> Udv
>
> A tema irant erdeklodoknek irtam egy kis teszt pogramot...Innen lehet
letolteni:
> http://vega55.freeweb.hu/Project1.zip
> http://vega55.freeweb.hu/PrioritasTesztForras.zip
> Mivel nem volt kedvem sokaig vacakolni vele, ezert Visual Basic-ban irtam
meg, igy a
> futtatashoz szukseges a msvbvm60.dll file meglete.
> Roviden a prog mukodese: a start gomb megnyomasaval egy adott(szabadon
> valtoztathato) prioritasu szal jon letre. Ez a szal letrehoz a futasa
elejen egy
> masik szalat, ami szinten allithato. Mindket szal belsejeben egy allithato
ciklus
> kezd el "mukodni". Normal esetben ezek kb egyforman futnak, ami latszik
is. Viszont,
> ha kulonbozo a szalak prioritasa, mar a sebesseguk is lenyegesen elter
egymastol....
>
> A tokeletestol nagyon messze van, de tesztelesre talan hasznalhato....:-)
> Csak Win2000 es Me alatt teszteltem, de gondolom a tobbi alatt is mukodni
fog...
> Ja, a latvanyos op rendszer "fagyasok" csak az Nt alapu Windowsoknal
> tapasztalhato(mielott valaki Win95-Me alatt varna ezt az eredmenyt)!!!
>
> Zoli

Nem artana helyesen programozni VB-ben
es jobban tisztaban lenni a rendszer mukodesevel......
mielott szal lefagyasrol beszel az emberfia

Ugyan irj mar egy form1.refresh -t a doevents-ek utan mindket helyre,
hogy legyen eselye a rendszer form rajzolo thraednek is futni!!!! amikor
a sajat timecriticaljaid futnak......ami nyilvan magasabb szint mint a VB
form rajzolasa.

neked ehat kerned kell az utemezot, hogy a time critical kozepen
ugyan utemezzen mar egy kissebb szintet is, mert hasznalod a kirajzolot.
Es akkor bizony a windows beutemezi a timecritical kellos kozepebe......
mert amig nem rajzol addig blokkolodik a timecritical thread, ahogy illik.

form1.refresh beirasa utan a class-t felteheted highpriorytira
a threadeket pedig time criticalra
allitsd a ciklust mondjuk 50000-re
es lon csoda!!!!

Még ezen a szinten is elkezd a masodik thread 13-18000 korul szamolni
(mert az elso idokvantum utan beutemezodik a masik szal is)
es utana egyutt szamolnak szepen parhuzamosan mert az
utemezo bizony DOLGOZIK a ket kibaszott timecritcalra is!!!!

Real timera is teheted a classt, de akkor mar nem nem megy a ket szal
parhuzamosan
mert  maga a VB runtime (ami a szal szuloje nem a realtime osztalyban lakik)
nem jut szohoz masodszor.....

Az, hogy ilyenkor mi tortenik, jo kerdes.
Szerintem fut ilyenkor is, csak nem azonos sorban az elsovel
a VB belso mukodese miatt.

Ugyanis:
Ha minden realtime (maga a VB exe is) akkor megfigyelhetsz egy erdekes
jelendeget!
Amig az elso szal fut, addig az eger fagyott, de
ahogy a masodik elindul szepen lejatssza az elso szal futasa alatti
egermozgasokat
es utana az eger a masodik szal alatt mar kezelheto :-)
Tehat az esemeny kezelo fut(utemezodik) a realtime thread alatt is csak, nem
jut szohoz
a user interface szinten.

Ez az eger viselkedes vagy arra utal,
hogy a kezzel szult thread nem ugyabban a sorban jon letre mint a
masik, ezert viselkedik maskent
vagy arra, hogy a kezzel szult is fut es gyujtodnek szepen a windows message
uzenetek
de a vegrehajtasra csak az elso utan kerulnek ezert bar
parhuzamosan futott a kijelzes csak utolag tortenik......

Ezt nem tudom eldonteni, erre valami progi kene ami logolja a
windows message uzeneteket esoffline lehetne elemezni oket.

De ezek gondolom a VB nyugjei, mivel nem ilyen osztalyu szalak
menedzselesere van tervezve.
C-ben gondolom, jobban kezben tarthatok ezek a dolgok es szepen menne
parhuzamosan a ket szal
meg realtime sztalyban is, mert a windows igy muxik, mivel preemptiv.

Szamomra ezek a jelensegek azt bizonyitjak, hogy en ertelmeztem jol a win
szalkezlest.....
A VB meg alapbol nem alkalmas realtime osztalyu tobbszalas munkara.


KJ