rovid ideju idozitesek PC-n

[Tantos Andras]

Hali!

Amit en csinalnek, az az, hogy a programomnak lenne egy az idozitesekkel
foglalkozo thread-je. Nem t'om pontosan mit szeretnel, de modjuk a feladat
byteok soros kikuldese megfelelo idozitesekkel. Akkor a thread 1 byte-ot
kuld ki, szepen bitenkent, ahogy kell, majd alszik amig a kovetkezo byte
megjon. A program tobbi resze meg adja szepen az adatokat ennek a
thread-nek. A trukk az, hogy a soros kommunikacio thread-jenek a prioritasat
meg kell novelni. Erre a

BOOL SetThreadPriority(
  HANDLE hThread,
  int nPriority
);

hivas valo a THREAD_PRIORITY_TIME_CRITICAL parameterrel. Ez szerintem eleg.

Ha nem akarsz multi-threaded programmal bibelodni, hivd meg a programod
elejen ezt:

BOOL SetPriorityClass(
  HANDLE hProcess,
  DWORD dwPriorityClass
);

A parameter legyen:
  REALTIME_PRIORITY_CLASS
    Process that has the highest possible priority. The threads of the
    process preempt the threads of all other processes, including
                                                        ^^^^^^^^^
    operating system processes performing important tasks. For
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    example, a real-time process that executes for more than a very brief
    interval can cause disk caches not to flush or cause the mouse to be
    unresponsive.

De ezzel nagyon figyelj oda, konnyen gyorsan le lehet fagyasztani a gepet.
Ha ezt hasznalod, ahol mar az idozites nem olyan fontos, altasd el a
programodat egy kis idore (Sleep(0)) hogy masok is szohoz jussanak. Ennel a
beallitasnal ugyanis a processzed prioritasa magasabb, mint az OS-e! azaz
pl. a disk-muveletek sem fognak megtortenni. Meg valami: ha ezt a megoldast
valasztod, en azt tennem, hogy minden adatot behuznek memoriaba, a memoriat
'lock'-olnam, hogy ne legyen virtualis memoria-muvelet sem, ezek *utan*
emelnem csak meg a program prioritasat, csinalnam, amit kell, majd amint
lehet vissza vennem a prioritast normal-ra.

Meg par megjegyzes: a programot alaposan debug-old ki prioritas-emeles
nelkul. Nezd at a programot haromszor: az emelt prioritasu resz nem kerulhet
veletlen ciklusba! Akkor sem, ha a kulso HW hulyeseget valaszol, nem
valaszol, barmit csinal. Soha! Lehet, hogy az egesz Win9x alatt nem fog eleg
jol menni, az (ujabb) NT-knek sokkal jobb utemezoje van. Ha viszont NT alatt
futtatod a programot, gond lesz a port eleresevel. Hasznald, a 'UserPort'
nevu programot vagy mas ekvivalens megoldast. Szinten NT alatt csodalkoznek,
ha nem kellene admin jog ahhoz, hogy a process-ed prioritasat ilyen magasra
allitsd. A leiras ennyit mond errol:

Windows NT/2000/XP: The handle must have the PROCESS_SET_INFORMATION access
right. For more information, see Process Security and Access Rights.

Hogy pontosan kinek van ilyen joga, azt nem tudom, az admin-oknak biztos.

> PIC programozot irok w98 ala assemblyben, mar teljesen keszen van, de
> az idoziteseket meg ures ciklussal oldom meg, igy ez gep es
> sebessegfuggove teszi a progit. Szeretnek valami univerzalisan
> hasznalhato otletetet a nagyon rovid (100ns) koruli idozitesekre. A
> portra iras/olvas fix ideig tart vagy az is chipset es sebessegfuggo?
> Valami 4ms koruli idozitesi otlet is kellene, de ezt talan mar le
> tudom trukkosen kezelni.
> Vegso otletkent arra gondoltam, hogy 1s-ig szamoltatok a geppel
> ures ciklusban es ez a szam fog a gep sebessegenek alapjaul szolgalni.
> De ez multitaszkos kornyezetben nem tunik tul jo otletnek...
> Valaki mas esetleg osszefutott-e ezzel a gonddal?
> A windows WM_TIMER-jet mar probaltam...

Ugy tudom a Windows-k 1ms koruli task-utemezovel dolgoznak. Azaz ennyi
bizonytalansagod minimum lesz, hacsak nem csinalsz valami olyasmit, amit
fent leirtam.

Udv,
Tantos Andras