AnsweredAssumed Answered

vrf AW: CPU Usage (was: Vee program sources)

Question asked by bernhardt on Dec 3, 2003
Hi,

in an older project we used a DLL containing the function SetPriorityClass.
This DLL works fine with NT. It was no problem to set VEE to "Realtime"
before the measurement starts and set it back to "Normal" after the
measurement. But don't forget to set it back.

Best regards
M. Bernhardt



-----Ursprngliche Nachricht-----
Von:      Shawn Fessenden [mailto:shawn@testech-ltd.com]
Gesendet:     Mittwoch, 3. Dezember 2003 10:32
An:     VRF
Betreff:     [vrf] AW: RE: CPU Usage (was: Vee program sources)

> Stupid physicist I am, thought - better: hoped - that there might be a
> way to cheat any thread-handle or whatever is inside the f*... OS to
> disable the graphical engine for a short period of time or to claim
> full system resources for VEE while executing a well-defined piece of
> code.

Ahh, but being a physicist you have hit the nail exactly on the head and
somehow divined exactly the correct solution. There are two such functions
in kernel32:

int __stdcall SetPriorityClass(int hProcess, long dwPriorityClass);

REALTIME_PRIORITY_CLASS     = 0x00000100
HIGH_PRIORITY_CLASS         = 0x00000080
ABOVE_NORMAL_PRIORITY_CLASS = ?
NORMAL_PRIORITY_CLASS       = 0x00000020
BELOW_NORMAL_PRIORITY_CLASS = ?
IDLE_PRIORITY_CLASS         = 0x00000040

In NT, the handle must have PROCESS_SET_INFORMATION access (when using
OpenProcess to get the handle, specify at least PROCESS_SET_INFORMATION
access).

int __stdcall SetThreadPriority(int hThread, int iPriority);

THREAD_PRIORITY_TIME_CRITICAL = 15
THREAD_PRIORITY_HIGHEST       = 2
THREAD_PRIORITY_ABOVE_NORMAL  = 1
THREAD_PRIORITY_NORMAL        = 0
THREAD_PRIORITY_BELOW_NORMAL  = -1
THREAD_PRIORITY_LOWEST        = -2
THREAD_PRIORITY_IDLE          = -15

In NT, the handle must have THREAD_SET_INFORMATION access (when using
OpenThread to get the handle, specify at least THREAD_SET_INFORMATION
access).

Beyond the documentation of these functions, I don't know much about it. The
task scheduler is bizarre in the extreme to say the very least. I do know
from personal experience though that you should really think twice about
using REALTIME in either call. It can take a LONG time to do anything else
at all with the computer once these are in effect. That was on a mere 40MHz
processor though.
-SHAWN-


---
You are currently subscribed to vrf as: Bernhardt@somatec.de
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Outcomes