assembly kod

[Balla Zoltán]

From: "HWSW Famulus" <hwsw at famulus.hu>
>Nem artana helyesen programozni VB-ben
>es jobban tisztaban lenni a rendszer mukodesevel......
>mielott szal lefagyasrol beszel az emberfia
>
Bezzeg te majd(legnagyobb oromomre) kijavitod helyesre, mivel te tokeletesen
tisztaban vagy a Win mukodesevel kapcsolatban...:-) Bar jeleztem, hogy ez egy
"otperces" program, igy van mit rajta javitani! Allok elebe! Tanulni sosem keso.
Eppen ezert van ott a forraskod...
De ha erre nem vagy kepes, legyszives ne fikazz masokat(magamat is beleertve)!!!

>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.
>
Na ez az, itt latszik, hogy nem erted a mukodes lenyeget!!! Nemhogy refresh-t nem
szabad(!) belerakni a ciklusba, de meg valojaban a doevents funkciot sem lett volna
szabad alkalmazni!!! Hiszen egesz ido alatt arrol beszelek, hogy ha nem adja vissza
a vezerlest a szal, akkor nincs ami elvenne tole! Ha olyan jol ismered a VB-t, akkor
tudnad, hogy a doevents visszaadja(!!!) a vezerlest az op rendszernek, hogy az
minden(!) bujat-bajat, egyeb kivansagait is kiszolgalja...
A refresh metodus szinten atadja a vezerlest az op rendszernek, de mar korantsem
olyan baratsagosan, mint a doevents! Jelen esetben pedig ennek a hasznalata teljesen
felesleges...
Igaz en hasznaltam a doevents, megpedig amiatt, hogy a szovegmezo(is !) frissitve
legyen a ciklus alatt. Annak ellenere tettem ezt, hogy mint irtam , ez visszaadja a
vezerlest a rendszernek teljes mertekben. Vilagos, hogy ekkor a feledat utemzo is
megkapja a vezerlest... Ennek ellenere benne hagytam, mert meg igy is tokeletesen
alatamasztotta az en allitasaimat!

>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.
>
Ha jol ertem ezzel a kicsit nehezen kovetheto gondolatmenettel azt akarod mondani,
hogy mert szerinted nem megy a "kirajzolo" ezert nem is az tortenik , amit en
feltetelezek...??! Ugyanmar...

>form1.refresh beirasa utan a class-t felteheted highpriorytira
>a threadeket pedig time criticalra
>allitsd a ciklust mondjuk 50000-re
>es lon csoda!!!!
>
Hat persze, ha a ciklusokat telerakod olyan utasitasokkal, ami eleve visszaadja az
op rendszer kezebe az iranyitast, mit varsz ???! Vilagos, hogy ez igy van....
Meg egyszer es utoljara, en arrol az esetrol beszelek, amikor a cikluson belul
nincs(!!!) olyan utasitas, amit az op rendszer szolgal ki! Ezt probald megerteni,
mert ezen all vagy bukik az egesz prioritas tema....

>utemezo bizony DOLGOZIK a ket kibaszott timecritcalra is!!!!
>
azert remelem, te nem sulyedsz le VF szintjere....

>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.....
>
Jo magyarazat...! Csak egy kicsit teves szerintem... Mivel mindket szal (vegso
soron) API hivassal kepzodik, ezert a tovabbiakban szinte semmi koze nincs a
VB-hez!!! Ha nem hiszed ird at a programot C-be, es meglatod, nem valoszinu, hogy
maskeppen fog viselkedni....
De addig is, kiteszek egy masik valtozatot, amiben mar ket szal keletkezik
egyszerre, nem pedig ahogy eddig tortent!!! Sot raadasul meg a ciklusbol is kihagyom
a doevents-t, igy mar tenyleg csak akkor kapja meg az op rezndszer a vezerlest(meg
mindig!), amikor a szovegmezo frissul...Itt meg erdekesebb dolgok tortennek a
real-time prioritas alatt, kulonbozo op rendszerek alatt...Win2000 alatt az elso
szal indul el, es utana csak a masik(miutan letelt az elso), XP alatt meg
forditva!!!! Na ezt vajon a te allaspontod szerint mivel magyarazod??
Ez a masik verzio letoltheto:
http://vega55.freeweb.hu/Project1_2.zip
http://vega55.freeweb.hu/PrioritasTesztForras2.zip

>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
>
Ezt en is megfigyeltem!

>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.
>
Tevedes! Az eger hardware megszakitast okoz, ami kiszolgalodik valamilyen szinten,
es az op rendszer ezt meg is "jegyzi", majd az elso adando alkalommal(ha meg
lehetseges) megprobalja uzenetek formajaban el is kuldeni...
Az mar mas kerdes, hogy miert sikerul ez neki(ha reszlegesen is) a masodik szal
futasa !???

>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......
>
Na igen, ez amolyan Piroska es a farkas jellegu talalgatas...

>Ezt nem tudom eldonteni, erre valami progi kene ami logolja a
>windows message uzeneteket esoffline lehetne elemezni oket.
>
Talan akkor probald ki a Spy++ utilit-et a Visual Studio-bol. Hihetetlenul hasznos
program...

>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.
>
...ezt mar hallottuk toled nem is egyszer, de hol is az a C-s program ???!

>Szamomra ezek a jelensegek azt bizonyitjak, hogy en ertelmeztem jol a win
>szalkezlest.....
>A VB meg alapbol nem alkalmas realtime osztalyu tobbszalas munkara.
>
Persze, ahogy egyesek szerint valamire valo programot sem lehet irni benne...!
Nevetseges...

Zoli